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A Cycle 3 update of the Integration Procedures Notebook is 
now available* The Notebook has not changed a great deal 
since its extensive revision at Build Q» but there are some 
changes of interest in the utility procedures* described in 
Section 2.11> end the CYBlL build process* described in 
Appendix C» Keypoint information has been added to the 
document in Appendix D» A complete listing of tnis document 
can be obtained through the following command sequence: 

ATTACH,IPN00C/UN«D£V1* 
SSS.^RINT IPNOOC 
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1.0 NOS/VE SYSTEM OVERVIEW 
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1.1 ISiaOQUtllflH 

The basic components of NOS/VE Include the following! 

A Hardware Initialization Verification Sequencer 
CHIVS) component 

- Modifications to standard A170 NOS system components 

- A170 NQS application programs (and procedure files) 
which execute In the A170 NOS {Real State) 
environment* and provide system to system 
communication facilities* 

The Virtual Environment code which is responsible for 
the execution of tasks In Native Mode in the Virtual 
State of the hardware* 

The nomenclature used to describe NOS/VE components Is 
rather confusing. Frequently* the Virtual system software is 
what is referred to as "NOS/VE*** When A170 NOS and the 
supporting utilities are present* the term H 0ual State" is 
used* To differentiate the two execution modes of the machine 
the terms "Native Mode"* "Virtual Mode"* and "Virtual State" 
are used to describe the execution of C18G instructions* The 
terms "Real State" and "NOS" are used to refer to the 
execution of C170 instructions. 

The model which is often used to describe the execution of 
NOS/VE in Dual State mode is that of one machine front-ending 
another* and communication between the two machines occurring 
over a communications link. From the software»s point of 
view* another perspective is used. To the Virtual State 
software* the NOS system is merely a job which happens to be 
executing in the Virtual State envelope created by EI. (The 
microcode translation of the C170 instruction set is 
"invisible" to both the NOS and NOS/VE software*) N0S f s view 
of the Virtual State is merely that of a job which runs at a 
control point* and is communicated with through the 
K-display. The remainder of this section is meant to describe 
NQS/VE with regard to its components. 
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1.1.1 THE HIVS COMPONENT 

Included in the diagnostic world* which establishes the 
Initial Virtual Execution environment* Is the microcode for 
the CPU as wel I as a Native Mode monitor-like program called 
the Error Interface (ED* The microcode Is strictly supported 
by the diagnostic organizations* and neither the NOS nor the 
NOS/VE software will execute without microcode present in the 
CPU. The EI program is supported by Advanced Systems 
Development. There are currently two versions of Elf one 
which only supports A170 HQS and does tasks such as CMU 
instruction emulation* and one which also supports the 
switching between the NOS and NOS/VE CPU monitors. This 
latter version of EI requires a partner intermediary called 
the N0$ Trap Handler which is statically loaded with the 
Virtual State software* and is loaded during deadstart of 
NOS/VE. In order to assure that the right version of El is 
present* the HIVS tape which is distributed by Advanced 
Systems Integration for use with NOS/VE is the correct version 
to Insta 1 1 . 



1.1.2 A170 NOS MODIFICATIONS 

The modifications required to support a Dual State 
execution environment are primarily assembled in the BLD17G 
procedure file, pew specifics will be given here other than 
to state that half a dozen Peripheral Processor routines are 
involved* as well as modification to NOS CPU Monitor. The key 
aspect to note about these components is that a special 
version of A170 NOS deadstart tape must be used. Again* this 
deadstart tape version Is supplied by the Advanced Systems 
Integration project. There are additional procedure files 
which must also be present on this special deadstart tape* 
which are not documented here at this time. 



1.1.3 A170 NOS APPLICATIONS 

A portion of the software alluded to as A170 NOS 
modifications could be classified as A170 NOS Applications. 
The applications referred to* however* are not present on the 
deadstart tape* but exist as permanent files which are Invoked 
or processed by procedure files present on the deadstart 
tape. In the strict sense of the word* those utilities which 
are not execution order dependent or require system residence 
are placed on the deadstart tape. Utilities which must be run 
in a given sequence (and possibly as system origin) are 
governed by procedure files which are present on the deadstart 
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tape. 



1.1.4 THE VIRTUAL STATE COMPONENT 

The Virtual State software consists of both a statically 
and dynamically linked component. The statically linked 
component Is composed of Monitor and Task Services modules 
while most other tasks are dynamically linked. In order to 
statically link Monitor and Task Services* the SES utilities 
VELINK and VEGEN or their Virtual State equivalents must be 
used. In other systems this statically linked system 
component is commonly referred to as the "unconfigured 
deadstart tape** or "bootstrap system*. Once the H bootstrap 
system" has been generated which has its own LINKER/LOADER 
equivalent* then it is possible to deadstart this bootstrap 
system and begin dynamic link/loads. One of the attributes of 
this statically linked component is that there is more than 
one partition associated with it. In order to keep these 
partitions separate during the CI build process* these 
partitions are placed on separate files* The content of these 
partitions is described in a subsequent section of this 
document. 

The dynamically linked component of the Virtual State 
software consists of II format object text which Is processed 
by the NOS/VE LOADER. In order to create II format object 
text* it is necessary to either use the utility "CITOH* to 
convert CI object text to II object text* or else use a II 
compiler or assembler. In order to make this CITQII utility 
available to each task created by the Virtual State software* 
the object text for this utility must be statically linked and 
loaded with Monitor and Task Services. Once this utility is 
made available to dynamically generated tasks* it is necessary 
to retrieve the other utilities which establish communications 
with their A170 NOS counterparts* This is accomplished by 
executing a post-deadstart SCL procedure file which Initiates 
the Remote Host and Interactive Facilities from the library 
"0SLI8" Cwhich in turn was created from the CI object text 
file "XLJOSL"). 

The components mentioned thus far have been the statically 
linked modules for Monitor* Task Services* the CITOII utility* 
and the dynamically linked modules from OSLIB* There are 
libraries other than OSLIB* some of which are necessary for 
the successful execution of user tasks* Such a library is 
SYSLI8 which contains the Object Code Utility modules which 
provide for the creation of II object text libraries* The 
SYSLI8 library must be made part of a job»s object library 
list If any II object library manipulations are to be made, 
from the compiler perspective* the run-time libraries CYBILIB* 
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MATHLI8* FRTL* etc. must be created by a job which has SYSLI8 
as part of its object library list* The compiler generated 
object text for a compiler such as CYBIl names the appropriate 
run-time library in the object text records (eg. CY8ILIB). 
Thus* a CY8IL program must access the appropriate run-time 
library CCYBILIB) and make this library part of the job f s 
object library list. This explicit manipulation of a job*s 
object library list will eventually be replaced by job 
prologues which are created during accounting and validation 
and/or user prologues which establish a job's execution 
envi ronment • 



1.2 miUAL-SIM£-£MIIII0M!3Si 

Build Q reflects Phase 2 of the restructuring of the NOS/VE 
operating system into two distinct partitions - the system 
core and the job template. This restructuring is necessary in 
order to reach the Rl goal of deadstarting NOS/VE in 1MB of 
memory. In this system the system core will be able to 
deadstart and support tasking, littiaiit the job template. This 
was completed in Build P. 

The system core contains monitor* the NOS Trap Handler* and 
all code that executes in ring 1# and consists of the 
following libraries: 
XLMMTR - Monitor mode procedures. 

XLS113 - Job mode procedures that have static data* write 
Mainframe wired, Mainframe Fixed or Job Fixed, or 
make privileged monitor calls (these are most of the 
modules that used to reside in XLJ11F). 
XLS133 A small subset of the procedures 
XLS123 . that used to reside in XLJ12F, 
XLS13D XLJ13F* and XLJ1FF that are 
XtSlDD needed by the system core. 

In the restructured system* modules in the system core cannot 
XREF variables or procedures that are part of the job 
template* and Indeed need not know nor depend upon any job 
template code. The job mode segments that come from the 
system core will be in the address space of every task 
(regardless of job type) and will have the same segment 
numbers. Code cannot be added to or deleted from the system 
core without a deadstart. 

All the rest of the operating system code that does Qfli 
reside In the system core is found in the job template. This 
code consists of Job Monitor and ring 3/run anywhere task 
services* contained in the following libraries! XLJ223, 
XIJ23D, and XLJ2DD ( XLJ236 and XU266 are linked in, but are 
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empty In 3u i I d Q). In the restructured system* there may be 
multiple job templates deoending upon the specific 
requirements of the various jobs in the system. These job 
templates nil I be staged across the memory link Mtt&L the 
system core has been deadstarted. 

The modules on file XLJB8B consist of user tasks which can 
be thought of as belonging to a third type of partition. This 
latter partition contains routines which run In job mode in 
the user ring (for the purpose of converting CI compiler 
generated output into II format after it has been transferred 
fro« the A170 NOS software to the NOS/VE execution 
environment). In the memory man* which Is described in a 
subsequent section* the code for this user partition resides 
in the "User Task(s) Library" and is made a part of each task 
created for NOS/VE. The system restructure which occurred 
with Build H made this partition relatively small (since this 
partition must be loaded into memory at deadstart time). 
Although the build procedures allow for this partition to be 
replaced with one which contains additional user tasks* the 
preferred method of executing user tasks is to GET them from a 
NOS permanent file (after they have been generated by a CI 
compiler) to the NOS/VS execution environment and EXECUTE 
these tasks using the NOS/VE LOADER. If the execution 
environment is the simulator instead of the hardware* then new 
user tasks should be statically loaded in place of XLJBB8 
using the NVELINK procedure. 

Any XDCL f d symbol within a given partition can be XREF'd by 
any module within the same partition. To allow other 
Partitions to XREF these same symbols* the symbols must be 
gated. Gating a symbol only makes the symbol available to 
other partitions during the linking process* it does not 
necessarily mean that the XOCL'd location can actually be 
referenced - that Is controlled by the ring brackets. In 
general* only selected XDCLfd symbols are gated. A variable 
or entry point may be gated in the source specification using 
CYBIL and CPU ASSEMBLER language constructs* or the object 
text may be modified by using the SES Object Code Utilities. 
Refer to the MAPXX file* produced by the NVELINK procedure* 
for a list of the entry points available to a user task. A 
convenient listing of these entry points can be obtained by 
running the MAPXX linkmap file through the procedure NVEMAP 
and specifying the keyword "TWO". The gated entry points are 
flagged In the section entitled "PVA* NAME SORTS" at the end 
of the NVEMAP linkmap output. The NVEMAP keyword "GATED" will 
list only thoses entry points which are gated (see the 
documentation for the procedure NVEMAP in Section 2 of this 
document). 

Occasions arise in which procedures are of common utility 
to more than one partition* but should not be gated across 
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partitions* In such instances* these procedures are pieced 
upon a tt run-time w library such as CYBILI8* and references to 
these procedures are satisfied at "LOAD** time from the 
appropriate library* "LOAD" time satisfying of externals can 
either be done statically or dynamically* A static load is 
accomplished through the SES Linker and Loader utilities* 
Dynamic loads occur through the use of the NOS/VE loader 
during the execution of a €180 job* Whenever possible* 
dynamic loading of routines is Preferred (as in the case of a 
compiler satisfying externals from a run-time library) since 
this is the mechanism which customers of NOS/VE systems will 
be using* 



1.3 MA!il£ULAIlQti.Q£-tiQiZ^«£4aiIIiatiS-MjD.lIfifiASI£5i 

When building a system* monitor must be linked first* All 
gated symbols within monitor then become available to task 
services* which is linked second Although some monitor symbols 
can be referenced by task services* the only way to execute 
monitor code is via the exchange jump - i*e*» the CALL/RETURN 
mechanism is not valid for use between monitor and job modes. 
User tasks are linked last and can reference gated symbols 
defined In task services* It is important to note that 
although the linker will allow a reference to a given symbol* 
the ability to actually reference the location is determined 
by the ring brackets on both ends of the reference* 



1 * * ■ aUAL-SIAI£-H£ttOBI-!!l£ 



When dealing with a virtual memory system it is often 
necessary to understand the real memory aspects of the 
software which is present in the machine* The following map 
describes the real memory aspects of the software* and where 
it Is mapped during the deadstart process* To make this map 
complete would require overlaying it with segment and page 
boundaries* Rather than attempt to produce this overlaying 
effect* suffice it to say that (by convention) the boundaries 
described In this map occur at even page boundaries* Whether 
or not the pages which constitute any given area in the map 
are paged is a function of the attributes of the segment to 
which the area belongs* 

The real utility of this map is in showing the relationship 
of values which are supplied to the SES Virtual Environment 
Generator through the skeleton SYSXDIR file. This skeleton is 
dynamically edited when the NVELINK procedure is invoked to 
produce the <iw>XLDR file. The SYSXDIR variables are 
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underlined in the relationships described after the map. By 
using the relationships given* it is possible to compute the 
relative starting locations of different areas within a NOS/VE 
dump. 

It should be noted that the relationships given here are 
expressed in decimal byte addresses* while the machine 
addresses are hexadecimal* To pursue hexadecimal addresses 
requires a copy of the linkmap file. Specifically* the load 
addresses for Monitor, System Core* Job Template* etc are 
contained in the Virtual Environment Generator output which 
immediately follows the LINKER output. 
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A170 NOS Operating System 
(Central Memory) 



< Machine Address C (zero) 



/ / 

/ NOS Extended Memory (ECS) / 
» * •. 

* » X* 



+~ 



J NOS/VE Page Table 



J< 



Maximum NOS Memory Address 
Load Offset 



NOS/VE Monitor 
NOS Trap Handier 



J< Virtual Load Address 



/ 

/ 
» 



NOS/VE Task Services 
(System Core/Job Template) 



{Available Memory Pages> 



/ 
/ 

!< NOS/VE Length 

+ 



NOS Page Table and EI 



!< Highest Machine Address 
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The Integration process begins with the transmittal of a 
software products the command language procedures required to 
build the product* installation procedure documen tati on* and 
baseline documentation from the software development 
organization. Subsequent to this transmittal* the Integration 
project Is responsible for maintaining the program library* 
standardizing the installation procedures* maintaining the 
Installation procedure documentation* and preparing the 
software release package for the Software Manufacturing and 
Distribution organization. In the interim time between the 
initial transmittal and the release of a software product* the 
Integration project schedules periodic builds* The outputs 
from these builds are delivered to software development and 
test organizations and/or mtde Part of the software release 
package* 



2.1 ££UI£2-fia£ytl£!iiS 
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2*2 siMMans 

In order to facilitate the Installation process* certain 
standards will have to be set and adhered to by all members of 
the Operating System and Product Set. These standards will 
cover the following items* 

a) All program libraries will have the same format* this 
will be defined by (TBD). 

b) All output tapes will conform to some predetermined 
format in terms of numbers of files and what each file 
will contain. This will be defined by <T8D). 

c) The above formats are intended to facilitate 
establishment of procedur al I zed installation decks. 
This Implies that some convenient naming conventions 
must be observed* These conventions will be defined 
by CT8D). 



2. 3 aAI4La£-Mii££M£ai-mi£I£S 

The Integration project builds two systems in parallel and 
manages two catalogs for each system. The primary system is 
the system that is between the beginning of the build cycle 
and the feature code cutoff. The secondary system is between 
the feature code cutoff and the er\4 of the build cycle. 
Primary system files begin in the INT1 catalog and move to the 
INT2 catalog after the system has passed Confidence Testing. 
After a system has reached its feature code cutoff* a 
stabilized feature build is moved to the DEVI catalog* the 
build from INT2 is moved to DEV2* and this system is now 
considered the secondary system. Also at this time* a new 
primary system Is started in the INT1 catalog by adding its 
planned feature code to the previous primary system. When a 
build has completed its integration cycle* the final build for 
that cycle Is moved to the REL1 catalog. It is at this time 
that a build is considered a candidate for transmittal to 
other facilities for further development work* a final Build 
Content Report is distributed and whatever usage documentation 
that is available Is distributed. 
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The following diagram illustrates the function of each 
catalogi 

♦— — — — — - * +' — +- ■ + — ■ • — + 

S J Primary System I Secondary System J Transmitted System! 

+ _ . , «., + ~ + -, , + , + 

! Working Catalog J INT1 \ DEVI ! — - \ 

+„_• _.. — + _ + _ + . . . + 

5 Latest Stable I INT2 5 DEV2 J R€L1 5 

! Build Catalog I J ! ! 

♦— — < ■ + ■ +- ■ + + 

In general* Procedures executing from a given catalog 
access only those files which have the same level of 
verification associated with them. The INTl and INT2 catalogs 
will access the most recent compilers* SES tools* etc. while 
the DEVI and D£V2 catalogs access a previous* more stable 
level of uti l| ti es« 

The REL1 catalog represents the "frozen" catalog for which 
changes are no longer being accepted (typically a snapshot of 
the last build cycle). This is generally the system that is 
being run in SVL closed shop and is retained for duplicating 
problems found there. The REL1 catalog will change no more 
frequently than once for each build cycle. The INT2 and D£V2 
catalogs contain the latest stable builds (i.e. the builds 
have passed Confidence Testing) for the primary and secondary 
systems* respectively. The INTl and DEVI catalogs* however* 
are "working catalogs" for the debug of new system fixes* new 
procedures* etc. The stability of these catalogs cannot be 
predicted. 



2.4 flUILfl-££flCEDU&£-fl£S£fiI£IIQM5 

In order to understand the procedure descriptions which 
follow* something should be said as to the sequence in which 
these procedures are used to generate systems. The following 
is an attempt to accomplish this: 



2.4,1 INTRODUCTION 

The command language procedures corresponding to NOS/VE 
builds all reside in the INTl* INT2* DEVI* or DEV2 catalogs 
depending upon the desired level of verification the system 
has attained. It is assumed that the DEVI level of 

verification is the minimum level of system verification 
required by most users* therefore the DEVI catalog is 
frequently referenced in the remainder of this section. To 
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obtain a listing of the complete set of command language 
procedures provided In the Integration catalog* execute the 
following command language sequence? 

SES.LISTPROC 8«SESPLIB UN»<In tegr a ti on_Cata I og> 

Before running the build procedures as batch jobs* a check 
must be made to insure that the user number under which the 
job ail! run has sufficient validation limits for the job to 
execute. The minimum values for certain limits must be as 

fol I OHSt 

CM * 24378 

NF ■ un I imi ted 

MS » unl imi ted 

DS * 4096 

EC * 2008 (If simulator is to use LCM) 

DB » unlimited (each library is built via batch job) 

The current values may be obtained with the LIMITS control 
statement. If they are not large enough* have the operations 
staff change them. 



2,4.2 INVOKING THE PROCEDURES 



The procedures described below are documented es 
"SES »<Pr ocedure_Name> w . In actuality* to invoke the 

procedures in this manner assumes that there is a file named 
•PROFILE 1 in the current catalog which names the Integration 
catalog to search for the procedure (via the 'SEARCH* 
directive)* The alternative mechanism for invoking these 
procedures is to code the procedure call ass 

"SESf <Integratlon_Catal og>.<Procedure_Name> w . Many of the 

procedures use the •PRCUNAM* value for subst i tutabl e user 
names* meaning that the catalog in which the procedure is 
fouftd is the catalog which is searched for files. This is as 
it should be* since each of the Integration catalogs contains 
a different version of the system. 

AM of the procedures described in this document have 
•"HELP" documentation associated with them. Use the 

SES*<Integration_C atalog>*HELP.<Procedur e_Name> call to have 
procedure documentation printed at your terminal. 

Practically all of the procedures described in this 

document are written to execute in ♦•BATCH" as well as locel 

mode, in order to provide a consistent result when these 
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procedures are run* it is necessary to save many of the 
generated flies as permanent files. While some purists see 
this as "catalog poiution w # we make ail attempts to preserve 
only those files which are necessary for future reference or 
usage. Whenever possible local file names generated by the 
Procedure are given unique names so as not to conflict with 
any user files. In numerous instances* convenient "reserved" 
file names are used to enhance the configurability of these 
procedures. For example* all files accessed by the procedures 
are searched for first as local files* then as permanent files 
in the catalog in which the procedure is executing* then 
(optionally) in the catalog specified by the 'AREA' parameter 
value* and finally in the catalog in which the procedure was 
found. Thus* if the name of a tool accessed by the procedures 
is known* several versions of this tool can be tried through 
iterative executions of the procedures without requiring 
procedure modification. To aid in the isolation of tools 
accessed by the procedures a "common deck M type structure is 
included in the procedure libraries which names many of the 
tools to be accessed by the procedures. These structures 
exist as records on the procedure library which are INClUDEd 
Into the relevant procedure file. Initially we have 
partitioned these tools into the records •TOGLALL 1 * »T00L170 , # 
and , T00Ll80 f . Experience has shown this part i t i t ioni ng to be 
somewhat corebersome for some of the procedures* and will 
probably be fine-tuned in subsequent revisions of the 
procedure library* 

Some of the procedures contained on the procedure libraries 
change very frequently due to changes in system structure or 
for other reasons* It is inevitable that errors creep into 
the procedures at times. Often it is quicker to change the 
CCL generated as a result of invoking the SES Procedure than 
to change the procedure library* The SES processor may be 
invoked via the SES*TEST. <Procedur e_Name> mechanism and the 
resultant CCL is written to a file named SESTEST. This 
SfSTSST file may then be edited* and the offending control 
statement corrected. A subsequent CALL*SESTEST statement may 
then be used to execute the corrected CCL. While we do not 
necessarily condone this approach to fixing procedure files we 
can hardly deny Its existence. If* for example* it should 
prove necessary to provide our customers with installation 
procedures for software which we generate with SES procedures* 
it would be our intent to ship the n SES generated CCL 
statements rather than the SES procedure and a copy of the SES 
processor. 
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2.4.3 CURRENT PACKAGING OF NOS/VE SOURCE 

There are two execution modes of NOS/VE which are referred 
to as the "standalone" mode and the *»dua l-state" mode. Ail of 
the NOS/VE source modules which execute \n the CY180 Virtual 
State are contained on a program library named •NOSVEPL*. The 
program interfaces to the Virtual State system* those 
described In the NOS/VE program Interface ERS* exist as common 
decks on a program library named •OSLPI 1 . The content of 
these two program libraries is referred to as the standalone 
system. A deadstart tape can be produced of the standalone 
system for execution on the hardware* or the output of the 
Virtual Environment generator can be executed directly on the 
Hardware System Simulator. The I/O support of this standalone 
system when running on the simulator is defined in a separate 
set of common decks on a program library named •CYBICHN*. 
Refer to the Simulated I/O ERS for documentation of these I/O 
interfaces. 

The dual-state execution of NOS/VE* in conjunction with the 
NOS operating system* requires NOS system modifications and 
the presence of a set of NOS utilities and procedure files. 
The software which supports this dual-state environment from 
the •NOS 1 side of the hardware is contained on a program 
library named •VE170PL 1 . Included in this package of NOS/VE 
support programs is a software application called the Remote 
Host Facility which supplies job-to-job communication between 
the Virtual State and NOS portions of the CY180 machine. 



2.4.4 UPDATE THE SOURCE LIBRARIES 



The Integration project typically updates the base source 
libraries prior to starting any recoup! I at ion or assembly of 
the system. In order for a user of these procedures to modify 
the source of a system routine he/she can use the SES 
•GETNODS 1 procedure to extract the source being modified* or 
create the source in some other manner* If GETMODS was used 
to extract the source* then REPNODS can be used to put this 
changed source on a MADIFY program library in the useMs 
catalog. Then the filename containing this program library 
must be specified as the value of the 'AB* parameter of the 
NVEBILD procedure. (Refer to the Source Maintenance Section 
of the SES User's Handbook if you have questions about source 
maintenance.) 
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2.4.5 C0HPIIE/ASSEH8LE FRQ1 SOURCE 

The efficiency of the Integration build procedures is a 
function of how much of the system is being built and how much 
information is supplied to the procedures when they are 
invoked. If the name of each module to be recompiled and its 
object file residency is known prior to invoking the 
procedures* then the most efficient method is to use the 
NVEBIID procedure and specify the lists of module names and 
library names via the *M* and H* parameters. If only the 
module names are known* then the NVEBIID procedure with the 
•M 1 parameter specified should be used (a search for the 
library names will be used). If only a modset file is 
available* the scope of changes is not readily apparent (i.e. 
severe! common decks are changed) or the number of modules to 
be recompiled is prohibitively large for manual specification 
to the NVEBILD procedure* then the NVEBLD procedure can to 
used to automatically generate the correct NVEBIID procedure 
calls (using a NOSVEPL cross reference). If it has been 
determined ahead of time that several modules on the same 
library are being changed* then It is more efficient to 
rebuild the entire library using the , L I parameter of the 
NVEBIID procedure. If several libraries need to be rebuilt 
(as in a full system build)* then the NVEBILF procedure should 
be used. 

The general phi losopy behind the NVEBILD procedure is to 
extract the latest source of a module from a program library* 
compile or assemble the source to Produce the appropriate 
object text* replace/ add the updated object text to the 
appropriate system library* and save this library in the 
catalog in which the procedure is executed. The final result 
of the execution of the NVEBIID procedure should be an updated 
system library in the current user f s catalog which is ready 
for the •LINKER* phase of the build. Jobs which run in "user 
mode*** that Is the interface to the system is o.nJLy. through use 
of the program interfaces (OSLPD* are saved merely as object 
text files in the user's catalog and LINKER-LOADER directive 
modifications are required to include these files as part of 
the system. This latter capability will gradually be replaced 
by the Virtual State LOADER and Library Generator features as 
they become available. 
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2.4.6 BEGIN THE LINKER-LOADER PHASE 

The LINKER <S£S53A6) and LOADER (SES53A5) are packaged 
together in the Integration procedure NVELINK. This is for 
convenience purposes* In that most LINKER changes to the 
system require a corresponding LOADER directive change* and 
the intermediate results from the LINKER execution are not the 
primary output used for system checkout. Prior to starting 
the LIMKER-LOADER phase of system builds* some decisions need 
to be made as to the target execution environment for the 
resultant output. 

If the target execution environment is standalone NOS/VE* 
then the •LW*SIM * parameter to NVELINK should be used to 
produce the file named f SlMXX». This file can be run on the 
simulator using the NVESIM procedure, or can fee used to create 
a deadstart tape using the »VSN* parameter of the NVESYS 
procedure* 

If the target execution environment is a dual-state 
environment* then the *LW»SYS f parameter must be used 
flrst*then •LW*J08 f . The « SYSXX. JOBXXYY' file is used by the 
NVESYS procudure to produce a deadstart tape image on disk 
named , TPXXXK , # which the dual-state deadstart procedure NVE 
will then find. Refer to Appendix D for Dual-State and 
standalone deadstart procedures. 



2.4.7 GENERATE THE DEADSTART FILE 



In order to generate a deadstart taoe for standalone 
NOS/VE. it is only necessary to run the NVESYS procedure and 
specify the VSN of the tape to be written. Prior to 
generating a dual-state deadstart file, however* it is 
necessary to verify that the utilities necessary to support 
the dual-state deadstart have been rebuilt via the DS8ILD and 
BLDEI procedures. There are two portions of the dual-state 
Ell the A170 portion Is built using the BLDEI procedure, and 
the C180 portion (the NOS Trap Handler) is rebuilt using the 
NVEBILD procedure <deck named OSANTH). 



2 * 5 tlX£flltll^ifl££aU&£.a£5£ai£IIfltl 

The procedure NVEBILD is used to add or replace modules on 
a base object text file. NVEBILD retrieves the source module 
frow a program library* using the following search order* 
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1) an alternate base optionally specified by the 
user (looking first in the current catalog* and 
then in the <In tegr at i on> catalog) 

2) OSLPI (from the <Integr at ion> catalog) 

3) NOSVEPL (from the <Integr at ion> catalog) 

This module is then compiled or assembled* and the 
resulting object text is either added to or replaced on a base 
file, A new version of the base file will be created in the 
current catalog* if •FULL 1 keyword is specified If • FU t I * is 
not specified* these procedures will create (or update 
existing) library file(s) in the current catalog* the 
resulting contents begin only the modules which were just 
compiled (added to any previously modi fyed binaries)* The 
names of the library file(s) will be the same as the 
destination integration library(s) for the modified modules to 
enable them to be merged with the integration binaries during 
the Unking phase. This applies to selected module 
compilation only ( »m* option). If the 'LISTING* parameter is 
specified a direct access file NOSLIST which contains the 
compilation or assembly iisting(s) of the module(s) compiled 
or assembled (one listing per record* headed by the matching 
MADIFY module name* will be created. If you specified 
•listing ■ tape vsn* then the listing will be archived to the 
tape, THl s listing can be listed via the LISTNVE procedure 
described in this document). If there are any compilation 
errors* the error listing(s) will be put on the direct access 
file ERRORS (which has the same format as NOSLIST) in the 
current catalog. The direct access file ERRLIST will contain 
a one line error message which indicates the type of error 
detected for all errors diagnosed by the procedures. By 
listing the ERRLIST file from a terminal* a summary of the 
number and types of errors encountered can be determined. 
There are conditions such as unrecoverable disk errors which 
can cause erroneous messages to occur in this file. In such 
case it is necessary to examine the DAYFILE produced by the 
procedure to isolate the problem. 

If a specified module is to be replaced (i.e. it is 
already part of the existing system)* NVEBILD will by default 
use the same compilation options and will replace it on the 
same base object text file as when it was first added to the 
system. These options may be overridden by specifying the 
corresponding parameters described below. 

If a specified module is new to the system* the compilation 
and base object text file options may be directly specified 
using the parameters described below. If a Hit of new 
modules Is specified* the compilation and base file options 
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must also be specified as lists* and NVE8IID will match 
everything up posi tiona! i y. If these parameters are aat 
specified* and NVEBILD is executing in LOCAL mode* a warning 
message will be issued telling the user that the module is not 
in the current system. The user will then be prompted for the 
necessary information. If these parameters are not specified 
and NVE8ILD is executing in BATCH mode* the compilation and 
base file options default as specified below* 

If the » I f parameter is specified • each module's object 
text will be copied to a temporary *z f file. The old library 
file will then be purged, and the *z» file will be renamed as 
the new library file. All compilation listings will be 
LI8EDlT«ed onto NOSLIST from a temporary listing file at the 
end of the procedure. 

Hhen an entire library is being rebuilt via the *M 
parameter* the module names and their corresponding 
compilation options are obtained from a file which contains 
all this information for each library. NVEBILD searches for 
this file first in the current catalog. and then in the 
<Integratl on> catalog. The name of this file iausi be the name 
of the library minus its first character (e.g. •LJ230 1 for 
the library *XLJ23D , )# and the first line of this file laust be 
the file name. To make additional entries or change existing 
entries in this file, the following procedure should be 
f ol I owedh 

1) EXTRACT,<libdeks>/UN«<Integration>. 

(where <|ibdeks> is the name of the compilation 

information file for the library as described above* and 
<Integr ati on> is the Integration catalog) 

2) Edit <libdeks> to add or change entries. The format and 
spacing of each entry is important and must be as follows! 

(<m>*<c>#<xref>*<ll>#<l2>) 
where 
m « a 7-character I eft- just If i ed module name 

c « a 1-character compilation option ( , , * , i , » or •3 I ; 

see description of , c i parameter below) 
xref » a 3-character left-justified cross reference 
option (either «YES» or 'NO •) 

11 » a 7-character lef t- justi f i ed destination library 
n ame. 

12 • a 7-character lef t- just I f I ed secondary library 
destination name. 

the entries currently in these files all follow this 
format so that any additional entries may be lined up 
quite easily with them. 

3) SAVE*<libdeks>. 



2-11 
ADVANCED SYSTEHS INTEGRATION PROCEDURES NOTEBOOK - Cycle 3 

05/22/82 

m mm mm mm mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm mm mmmmmmmmmm mm mmmmmmmmmmmmt 

2,0 OVERVIEW OF INTEGRATION PROCESS 

NVEBILD (with the * I f parameter specified) may then be used to 
rebuild the library using these nev»/modified compilation 
opti ons. 

The format of the NVEBILD is as follows! 

SES*NVE8ILD C m»(<module naie>, *<modul e name>) 3 

t I *< I i brar y name > 1 

C c»(<compi lat i on opt lon>* *<comp I I at ion option>) 3 

t area « < user name > 3 

C xref»(< xref opt i on>. .<xref option>) 3 

C listing* keyword or keywor d*<tape vsn>3 

C f ul I ■ keyword 1 

t ab * <alternate base> 1 

I omit * (<module n ame>. .<modu I e name)) 3 

C link * <parameter string for NVELINK> 3 

I test * <parameter string for NV£SIM> 3 

t print 3 

C batch 3 

m i The module name* or range of modules* or list of 

module names* 

I J The library name(s) onto which a newly compiled 

module (or modules) is (are) to be added or 
replaced* If the »M parameter has not been 
specified* then the entire library is recompiled. 
To recompile several libraries at a time it is 
recommended that the NVE8ILF procedure be used. 

c * c * to assemble a module 

c * 1 to compile a CY8IL module (DEFAULT) 

c * 3 to compile a CY3R module using CY8ICMN type 

decl ar at ions 

area t Option to obtain the object files or linker 

Parameter files from another user's catalog (other 
than the current catalog in which the procedure is 
executing). The default is for no area user 
catalog to be searched* 

lo * List options to be in force during CYBIL 

compilations* Hay be any combination of A* C» F* 

0# I» W# R> or (zero)* The default Is 
(zero) • 

ab * The user's alternate base program library 
containing new and modified modules. The default 
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is «N£WDKPL». 

omit i Used when running a full build* a module name or 
list of module names to omit from the build. The 
def aul t is none. 

listing i For producing compilation listing as a permanent 
file or archive the listing to the tape. 
The default is not to save the listing. 

full t To add or replace modified modules into object 

libraries. The default is only put modified 
module(s) into object library. 

link J String passed as the NVELINK parameter list* to 
optionally invoke the linker after compiling. The 
default is to not link the system. 

test t String passed as the NVESIN parameter list* to 

optionally invoke the simulator after linking. 
This parameter is invalid if the *LINK f option has 
not also been specified* The default is to not 
run the simulator test. 

print * Option to print the link map following the linking 
of the system. The default is not to print the 
I ink map. 

batch t Run NVEBILD in BATCH mode. The default is to run 
it local ly* 

£12 1£ * One of 'ui 1 or M 1 parameters musi be specified. 



2.5.1 NVE8ILF PROCEDURE DESCRIPTION 

MVEBIIF is an SES procedure file which submits one batch 
procedure execution of NVEBILD for each system library, each 
with the • I* parameter specified for the library to be built. 

The format of the NVE8ILF is as follows* 

SES.NVEBILF C I « <library name >3 
C batch I 
C I i st Ing ■ <t ape vsn>l 

I i The 'I* parameter specifies the library to be 

built. It can be one library or a list of 
libraries. The default is to rebuild the entire 
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system. 

listing: To archive the listing to the tape. The default 
is not to archive the listing to the tape. 

* batch \ Run NVE8ILF in 8ATCH mode. The default is to 

run it local I y* 

Note * To rebuild one library, the following are logically 
equi valent • 

1) SES.NVEBILF I »< library name > 

Z) SES.NVEBILD I -< library name > batch 

The expansion of either of the above procedures can be 
prohibitively long when being run from a terminal. The 
•batch 1 keyword on the NVEBILD procedure is implemented for 
the express purpose of freeing up the terminal for other 
purposes (the procedure expansion is done within the BATCHed 
job). 

2.5.2 NVEBLD PROCEDURE DESCRIPTION 

The NVE8L0 procedure generates and routes to the input 
queue a set of NVEBILD jobs which compile the modified or 
replaced decks and those decks which call modified or replaced 
common decks. First, NVSBLD finds the decks modified by 
creating a list of all the *D€CK lines In the , mf | file(s) and 
a list of all the decks in the »dkf f file(s). It combines the 
two lists, sorting and deleting duplicate names. The combined 
Mst Is checked against the current list of modules which make 
up NQS/VE, using the cross reference file from the *xrf» 
parameter. Then the procedure again creates two lists* a list 
of modules to be compiled and a list of common decks to be 
checked. A subset of the cross reference is used to generate 
a list of all decks referencing the given common decks. The 
list of modules and the list of decks referencing the modified 
common decks are combined, sorted and dupl Icates are removed. 
This final list is then used to generate the NVEBILD jobs to 
compile the necessary modules. 

The format of the NVEBID is as follows* 

SES. NVEBID C mf * <file.name> ] 

C dkf « <file„name> 1 

C xrf * <file_name> 1 

C nl * <l I br ary_n ame> 1 

C area * <user_name> 1 

C ab * <f I le_name> 1 
1 1 1st I ng * <tape vsn>1 
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mf t 



dkf * 



xrf t 



nl t 



area * 



ab * 



tful I * keyword 3 

C batch * local t defer I batchn 3 

The file or list of files which contains the 
modsets or a list of *D£CK deck_names. If the 
parameter is omitted the file NODFILE is used* 

The file or list of files which contains the new 
or replacement decks in a group file format. If 
the parameter is omitted the file DECKFIL is 
used* 

The NOS file name for the file containing the 
cross reference of NOSVEPL. If the parameter Is 
omitted the file XNVEPL is used. 

The list of library names to be omitted from the 
build. There Is no default. 

The search order to find any file. If the 
parameter is omitted the user names of the current 
user and the user name of the procedure are used 
for the default user names. 

The file name of the alternate base. The default 
is NEWDKPL. 



listing i To archive the listing file to the tape. The 
default is no listing is archived. 

full * To add or replace modified module(s) into object 
I i brar les. 

batch ! local ' defer 5 batchn i The job run mode of the 
procedure. If none are defined LOCAL is used. 



2.5.3 LISTNVE PROCEDURE DESCRIPTION 

LISTMVE is an SES procedure file which extracts the 
compilation listings of the modules specified by the 'M 1 
parameter (module names correspond to the MADIFY deck name 
given the module) from a text library file and writes them to 
the file specified by the •O* parameter in a printable 
format. The f M' parameter may select a single module* a list 
of modules, and/or a range of modules on the library file. 

The library file which contains the listings may be 
selected via the •!• parameter* and defaults to NOSLIST. 
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LISTNVE will search for this file in the current catalog 
first* and if it is not there it will go to the catalog 
specified by the MREA 1 parameter. 

When LISTNVE has completed* the output file selected by the 

*0* parameter will be a local file. It is aat automatically 

printed unless either the 'PRINT* or 'BATCH 1 option is 
selected. 

The format of the LISTNVE is as follows* 

SES. LISTNVE C m » ( <module name) • .<modu I e name> ) 3 

C i * <f i I e name> 3 

C vsn » <tape vsn> 3 

C o « <print file name> 3 

C area » <user name> 3 

I pr Int 3 

C fiche « <tape vsn> 3 

C batch 3 

m i The module name(s) and / or range of module 

names which are to be extracted for 
printing. The default is to extract and 
format all of the modules* 

i ' f » from t The name of the text library file from 

which the compilation listings are to be 
extr acted. 

vsn t Tape vsn. For archiving the listing file 

to the tape. The default is NOSLIST. 

o J to J upon i The name of the file which will receive the 

formatted listings to be printed. The 
default is LISTING. 

area » The name of the catalog to search for the 

library file should it not be found in the 

current catalog. The default is the 
<Integrat ion> catalog* 

print t Option to print the listing file after it 

is formatted. The default is to not print 
the I isti ng file. 

flche i Write listing output to the tape with this 

VSN in a format suitable for microf i ch ing. 
The default is to not microfiche the 
I 1st Ing. 



2-16 
ADVANCED SYSTEMS INTEGRATION PROCEDURES NOTEBOOK - Cycle 3 

05/22/82 

2.0 OVERVIEW OF INTEGRATION PROCESS 

batch i Run LISTNVE in 8ATCH mode. The default is 

to run i t loca I ly* 

2.6 HStELlHlt^&a££nU&£.D£S£&I£Iiaia 

NVELINK is an SES command language procedure file which 
mIH call both the VE Linker and VE Generator (supplied by the 
Development project) to produce various optional image files 
and link map files. In order to do this it will link monitor 
and task service routines from their object text files* It 
will search all files that it requires 1) from local files 2) 
from the current catalog* 3) from area user's catalog (if the 
area parameter is specified)* 4) from the < Integr at lon> 
catalog. 

It Is no longer necessary to keep complete object libraries 
in the current/area catalogs when modifications have only been 
made to a few modules. Instead* the cJajaaeji modules should 
reside on (an) object filers)* with the same name(s) as their 
destination object library(s); in the current/area 

catafog(s). NVELINK then applies these modifications on top 
of the current <Integra t ion> libraries* applying first the 
area catalog changes (if any) and then the current catalog 
changes (this function is oerformed by the SES GOF utility 
entirely on local files? at procedure end the libraries 
residing in the current/area catalogs remain exactly as they 
were before NVELINK was invoked)* This made necessary an 
option to dynamically 4e.le.Jte. modules no longer needed on a 
library. This is done via the »d' parameter* which specifies 
a file containing the name(s) of the module(s) to delete and 
the library(s) to delete it (them) from. This file jnilSi be in 
the format illustrated by the following example: 

F«<XLS13D)»H0DULE»(PHM$PR0GRAH_SERVICES. 
JMM$PR0GRA?1.LEVEL.INTERFACES#PMIi$SYSTEH^TIME^REQUESTS. 
MLH$HANDL£_ SIGNAL) 

F*(XLSlDD)#MODULE-(aSM$INTRINSICS) 

F*( XL J223)*M0DULE«(AVM$ INITIALIZE* AVN$ JOS.ACCOUNTING.KERNEL- 
AVMI JOB_LI*!ITS_MANAGER#CLft$R£AD_INPUT_FUE ) 
etc. . . 

Ufltfit Each new entry (flagged by M F» M ) sitst begin in column 
one of a new line. Aiso#each library file name and list of 
modules liiSi be enclosed in parantheses* 

NVELINK wilt link any one of the following! the Production 
System Core and/or the Recovery System Core* or the Production 
Job Template and/or the Recovery Job Template* The choice is 
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made via the »LW f and 'REC parameters (see description 
below). The following table indicates what output files are 
saved In the current catalog after NVELINK has completed* and 
what their various names are depending upon the f LW» and "REC 
opt! onst 



5 LW«J0B i L^f-SYS \ LW-JOB REC J LW-SYS REC 


checkpoint? PJB<ci dXji d>I PSY<cld> J R JB<c I d>< J I d> J RSY<cid> 
file t J ! ? 


linkmap ! PmP<cI dXjl d>l PHP<cid> !RMP<ci dXj I d> J RHP<cid> 


outboard * ! ! 1 

symbol I PJBST<cid> ?PMTST<cid>J RJBST<cid> ? RMTST<cid> 

tables ? IPSYST<cid>l 1 R5YST<cid> 


loader ' * ' I 

directives? JOBXLOR ! PSYXLDR J JOBXLOR 1 RSYXLDR 

file : : : i 

1 inker * * I J 

debug J PJBXD8G 1 PHTXDBG ! RJBxDBG S RJiTXDBG 
table J J PSYXD3G J S RSYXDBG 



where <cld> 
<jid> 



Value given the CID parameter* 
Value given the JID parameter. 



and 



To link additional user jobs into the system* create a file 
in the current catalog containing the commands needed to 
obtain all the necessary files as weti as a call to VELINK for 
each user Job to be linked. Specify this file via the ADD 
parameter* and NVELINK will pick it up and physically insert 
it into procedure command stream immediately following the 
last call to VELINK. IlM.IitSLt.iinft-iO-tlll5.Iilfi-!miI-bfi-tllJB 

The format of the NVELINK is as follows! 



SES. NVELINK 



< I ink opt Ion > 3 



Iw 

rec 3 

cl d « < core I d > 1 
ji d » < job id > 3 
ps « < page sizs> 1 
ptl ■ < page table length > 3 
d ■ < OEOM directives file name 
add * < additional links file > 
C uj » < list of object files > 3 



stf ing 
s tr ing 


for 
for 


NVESIH 
NVESYS 


> 
> 


3 
1 


1 










> 1 
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t nvesim • < parameter 

C nvesys * < parameter 

C dump /no dump 1 

t area • < user name > 

C debug 1 

C print * < link option 

t batch 1 

Iw * The link option* used to determine which 
"pieces" or variations of the system are to be 
I inked* 

LW * JOB links only the system job template 
(DEFAULT). 
Lw* * SYS links only the system core* 

rec * Option to link ko,£k the Production and Recovery 
System Cores/Job Templates (depending on the 
HW* selection). The default is to link only 
the Production System Core/Job Template. 

cid * Two character string which becomes the system 
core identifier and is appended to the names of 
the NVELINK output files to identify the system 
core version which was just linked or which is 
to be used in the current link of a job 
template. The default is ^XX 1 * 

jld * Two character string which becomes the job 
template identifier and is appended to the names 
of the NVELINK output files to identify the job 
template version Just linked* The default is 
•YY». 

PS t Page size of the target NOS/VE system* expressed 

In multiples of 1024 bytes. Values may be 1* 2* 
4* 8* 16* 32* or 64. Default is 8. 

ptl * Page table length of target NOS/VE system* 

expressed in multiples of 1024 bytes. Values 

may be 4. 8* 16* 32* 64* 128* 256, 512* or 
1024. Default is 32. 

d * The name of the file con tai n i ng t he information 
necessary to delete modules from libraries 
before linking. The format of this file is 
described above. The default is to not delete 
any object modules before linking* 

add t The name of the file containing the commands 



ADVANCED SYSTEHS INTEGRATION PROCEDURES NOTEBOOK - Cycle 3 



2-19 



05/22/82 



2.0 OVERVIEW OF INTEGRATION PROCESS 
2.6 NVELINK PROCEDURE DESCRIPTION 



needed to link additional user jobs into the 
system. The default is to not link in any 
additional user jobs* 

uj * (List of) object fiie(s) containing user 
programs which are to be linked into the system 
along with the library XLJ888. 

nveslm « String passed as the NVESIH parameter list* to 
optionally invoke the simulator after linking. 

nvesys » String passed as the NVESYS parameter I i st* to 
optionally build a deadstart file or stand-alone 
deadstart tape after linking. 

dump/nodump Option to print a memory dump of the system. 
The default is 'NODUMP*. 



area » 



debug * 



print i 



batch * 



Option to obtain the object files or linker 
parameter files from another user's catalog 
(other than the current catalog in which the 
procedure Is executing). The default is for no 
area user catalog to be searched* 

Option to save the linker output debug tables as 
permanent files in the current catalog. The 
names of these files* when saved* are given in 
the table above* The default is to aat save 
thes e f I I es» 

The print option* used to determine which 
Hnkmaps to print* The default is not to print 
the linkmap* If only the print keyword is 
specified* the linkmap(s) matching the H« f 
option selected is printed. 



Run NVELINK in BATCH mode. 
run it locally. 



The default is to 



2.6.1 LPF FILE DESCRIPTION 



The LINK commands used in the NVELINK procedure do not 
specify enough information to totally define the requirements 
of the linking operation. Many additional parameters are 
supplied to the linker through additional data files* This 
includes information such ast 
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-Ring Numbers 

- Segment Numbers 

- Segment Attributes 

- Execution Privilege 

Currently this information is supplied to the linker via 
the S£S Linker Parameter File (LPF) file* The linkage between 
the linker and the LPF file is activated by the 
LPF»<f i I e.name> parameter on the LINK commands* For the 
monitor linkage this information is on LPF file HTRXLC8* 
system core/job template linkage information is on LPF files 
SYSXLCB and J08XLCB. the XLJBS8 (and other optional user 
object files) linkage information is on LPF file BBBXLC8. and 
EI linkage information is on EILC8* 

2*6.2 SYSXDIR / LDR FILE DESCRIPTION 

The SYSXDIR file used by the procedure NVELINK contains 
directives to the CPF Generator which allow it to produce a 
checkpoint file from the segment files produced by the VE 
Linker* These directives set up the physical environment into 
which N3S/VE is placed* and include such things as the 
definition of the page size* job and monitor exchange package 
addresses* page table address and length, preal located segment 
array definitions, etc* 

SYSXDIR Is a "skeleton" file which is dynamically edited 
during the execution of the NVELINK procedure* depending upon 
the specification of the Lw*. PS» REC# and PTL parameters. The 
edited file Is then put on an indirect access file* named 
according to the conventions outlined in the M¥£LIl!l&-££a££ihJ££ 
&£&&£ij«£iQQ section, in the user's catalog* It contains the 
directives to the CPF Generator which set up the physical 
environment for that particular link* This file must remain 
permanent In the user's catalog after NVELINK has been 
executed* as the procedure NVESYS uses this file in building a 
deadstart tape* 

2 . 7 £A&4a£I£&-ft£^&I£Ifla.IAaU- AlD^l£iSAfi£ JLfillEUIfi-aillLIllMfi 



2*7.1 GENPDT AND BLDGPDT DESCRIPTIONS 

An SCL Parameter Descriptor Table (PDT) Is a sufficiently 
complicated "type* that its declaraton. in particular its 
initialization* in CYBIL is awkward. Therefore* a means of 
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easily generating a POT has been devised. 

G€NPDT is an SES procedure which provides for the 
generation of a PDT from a specification that is virtually 
identical to an SCI proc declaration (see the NQS/VE Command 
Interface ERS# ARH36C9) . 

The output of GENPDT is a file containing the CY8IL 
variable declarations for the PDT specified* As a general 
rule this file should be formatted using the CYBIL source code 
formatter. 

The format of the GENPDT is as follows: 
SES. GENPDT C i « <fi!e name>l 
I o * <f i I e name>l 

i i The name of one file containing one PDT 

declaration* Blank lines and continued lines 
are allowed* The default is INPUT. 

i The name of the output file. All lines from M* 

are echoed on this file in the form of "block" 
comments. 

See the ERS for Parameter Descriptor Table Generator for 
the PDT declaration format and examples (GPDTERS/UN»SCL) • 

The SES procedure BLDGPDT builds the generate parameter 
descriptor table program that is used by GENPDT* 

The format of the BLDGPDT is* 

SES. BLDGPDT t I « <file name> 1 
C b * <f i I e name> 1 

1 t The name of the file which will receive the 

listing. The default is LISTING. 

b* The name of the file which will receive the 

binaries. The default Is GPDTBIN. 



2.7.2 GENNT* GNVEMT AND BLDGHT DESCRIPTIONS 

SENMT Is an SES procedure which takes as input 1 or more 
CYBIL common decks containing Exception Condition Code 
definitions with status severity and message template 
specified in an accompanying CYBIL comment and produces a 



2-22 
ADVANCED SYSTEMS INTEGRATION PROCEDURES NOTEBOOK - Cycle 3 

05/22/82 

2.0 OVERVIEW OF INTEGRATION PROCESS 

2*7.2 GENHT* GNVEMT AND BLDGMT DESCRIPTIONS 

m mm mmmmmmmmmmm mmm mmmm mmmmm m m m *r m m m m m m m m m m m -m m m mm m m m m m m m m m m m m m m mm m mmmmm 

ready-to-compi le CY8IL module which consists of CY8IL 
variables that represent the message templates* The coreicn 
decks that are used as Input should be stripped of the MODIFY 
headers and the line COMMON* The CY8IL module produced would 
next be compiled and included with other object files so the 
message formatter can locate the message template* 

The format of the GENMT is« 

SES. GENMT C i « <file r)*me> 1 

C Id * <2-char act er identifier > 1 
C o « <f i 1 e name> 1 
C e « <f i le name> 3 

i » f J The name of the file containing common decks to 
be used as input. The default is INPUT, 

Id « A two-character product identifier. The default 
is OS* 

i The name of the file to contain the CYBIL module 

which is output. The default is TEMPLAT, 

e * The name of the file to be used for error 
listing output* The default is OUTPUT. 

The SES procedure BLDGMT bui ids the generate message 
templates program. generates the message templates for the 
operating system* and produces the message template object 
module and puts it in object library XLJ2DD* 

The format of the BLDGHT is as follows* 

SES. BLDGHT I I « <file name> 1 
C b » <f i I e name> 1 

1 « The name of the file to receive the listing* 

The default is LISTING, 

b t The name of the file to receive the binaries. 

The default is GMT3IN. 

The SES procedure GNVEMT produces the message template 
object module for the operating system and puts it in the 
object libary XLJ2DD. (It is INCLUDEd by BLDGHT and it 
INCLUDES GENMT.) 

The format of the GNVEMT is as follows* 
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SES.GMVENT C bl - <file name> 3 
C e ■ <f i 1 e name> I 

bl i The name of the file to receive the object 

module* The default is MTLGO. 

e i The name of the output file. The default is 

OUTPUT. 



2.8 tfOSZtfE-SltlUUIIQ*! 



2.8.1 RUNNING A SIMULATOR TEST (NVESIH PROCEDURE) 

NVESIM Is an SES procedure file which Mill run either a 
batch node or an interactive simulation of N0S/V8. This 
option Is selected via the »TEST* parameter. If 'TEST 1 is not 
specified* then the simulation will be run interactively. If 
a batch mode simulation is desired* then 'TEST* is used to 
specify the name of the file containing the NOS/VE test 
commands that are to be input to the simulator. The 'BATCH 1 
keyword must also then be specified. If the user wants to use 
his/her own simulator directives file. the • CMOS • parameter 
must be spec if led. 

NVESIM also allows the selection of the checkpoint file to 
be used for the start of simulation. A checkpoint file may 
also be optionally saved at the end of the test. The C180 
memory size may be changed via the *!iEM» parameter. 

The NVESIM procedure will create several permanent files in 
the user f s catalog if not run interactively. These are 
itemized as follows! 

H IQ11IEUI* This direct access file contains all of the 
output of the NVESIM procedure* including 

a copy of the command file used as input to the 

simulator (•TEST* parameter) 

the output produced by the system 

- the SESLOG fi le 

a reformatted keypoint listing 

— DEBUG output (if 'SIMDBG* was specified on the 
NVESIN cal I) 

a summary of all (paging) disk I/O (HIOLOG file) 
-■ the load map produced by the CITOII conversion and 
execution of XUUTL (SI^LOAD file) 
(optionally) a hex dump of the checkpoint file at 
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the end of simulation 
— the job dayf i I e. 
This file is autonat leaf I y sent to the line printer* 

2) ££££&&£• This direct access file contains the keypoint 
data produced by the simulator. It is reformatted by 
the procedure NVEKEY before being written to the file 
TOUT PUT. 

3) Uailf* The dayfile of the NVESIM job will be written 
to this direct access file should it terminate 
abnormal I y. 

Additional lyt if the »NCPF« parameter is specified. NVESIM 
will create 2 direct access files which together contain the 
NOS/VE environment at the end of simulation. The file 
specified by the 'NCPF* parameter will contain the current 
NOS/VE checkpoint file. The other file (formed by adding the 
character i O l to the 'NCPF 1 file name - which must therefore 
be six or less characters long) is used for NOS/VE memory 
pagl ng. 

The format of the NVESIM is as follows: 



SES. NVESIM 



test * < command file > 3 

cmds * < simulator directives fife > 3 

cpf ■ < checkpoint file > 3 

ncpf ■ < new checkpoint file > 3 

mem » < memory size in hex > 3 

nods 3 

run * < instruction count > 3 

si mdbg 3 

dump 3 

area ■ < user name > 3 

batch 3 



test i 
cmds t 

cpf i 
ncpf i 



The file containing the NOS/VE test commands. 
The default is to run interactively. 

Simulator directives file which should be 
supplied by the user. The default Is to use the 
one created by the NVESIM procedure. 

The checkpoint file used for the start of 
simulation. The default is W SIMXX W . 

The checkpoint file to be saved at the end of 
simulation* The default is not to save a 
checkpoint file. 
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mem * The C18G machine memory size* in hex* needed to 
run the simulation* The default is 
"50OQOGU6)". 

nods s Option to use the version of the checkpoint file 
from the <Integrati on> catalog which has already 
been deadstarted* The default is to use a 
checkpoint file which has not been deadstarted. 

run i A count of the number of suimulated instructions 
to execute* The default is 800000 instructions 
(or the profile variable value for •RUNCNT 1 ). 

slmdbg i Option to turn DE8UG on for the current 
simulator run* The default Is to run with DEBUG 
off. 

dump i Option to include the dump of the checkpoint 
file at the end of simulation as part of the 
NVESIM output, The default is not to dump the 
checkpoint f I i e, 

area s The name of the catalog to search for the files 
needed to simulate the system should they not be 
found in the current catalog* The default is 
the <Integrat i on> catalog. 

batch t Run NVESIM in batch mode* The default is to run 

it I ocal J y . 

2*8.2 NVEKEY PROCEDURE DESCRIPTION 

NVEKEY is an SES procedure file which creates a simulator 
generated keypoint trace file. The output of this procedure 
is the local file •KEYFILE*. 

The format of the NVEKEY is as follows! 

SES. NVEKEY £ kp f * < keypoint file > 3 

C format « < SIN ! HDW > 3 

C kd « < list of keypoint descriptor files > 3 

I area « < user name > 3 

kpf * The keypoint file generated by the simulator 
which is used as input to XXH7KEY. The default 
is *SESSNKF«. 

format t Specifies whether simulator or hardware format 
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keypoints are being processed* Default is 
*SIM«. 

kd * A file or list of files which define(s) the 
keypoint descriptions. The default is 
*KEYDESC«. 

area t The name of the catalog to search for the files 

needed to create the keypoint trace file should 
they not be found in the current catalog* The 
default is the <lntegrat ion> catalog. 

2.8.3 DUMPING A SIMULATOR CHECKPOINT FILE (NVEDUMP PROCEDURE) 

NVEDUMP Is an SES procedure file which makes a DSDI dump of 
a simulator checkpoint file. 

The format of the NVEDUMP is as follows! 

SeS. NVEDUMP I cpf ■ < checkpoint file > 3 
£ I « < output file > 1 
C dump « STND J ALL 1 
I print 1 

t area » < user name > 1 
C batch ] 

cpf ! The checkpoint file which is to be dumped. The 
default is "CKPT", 

I t The file which is to receive the dump output. 
This file will be a local file after the 
procedure has finished execution. It is ajQi 
automatically printed. The default is 
"DSDIOUT". 

dump i Option to either dump the environment according 
to ASID (DUMPaSTND) or dump the entire 
environment (DUMP-ALL). If W DUMP*STND M is 
chosen* then the DSDI directives are taken from 
the file DSDIX. which the procedure will search 
for first In the current catalog and then in the 
<Int egr at i on> catalog. The default is 
W DUMP«STND M . 

print ! Option to Print the DSDI dump output. The 
default is not to print the dump. 

area « The name of the catalog to search for the files 
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needed to make the D$DI dump should they not be 
found in the current catalog* The default is 
the <Integrat I on> catalog. 

batch J Run NVEDUMP in BATCH mode. The default is to 

run It locally • 

2 . 9 aUlLai&£-A_J3£AI2SIi£I-£ILE 



2.9.1 INTRODUCTION 



2.9.2 CREATING THE FILE CNVESYS PROCEDURE) 

V 

The SES procedure NVESYS builds a deadstart file from the 
image files created by the linking of the system. The f REC f 
Parameter allows the option of building either a Production 
System or a Recovery System deadstart file. If the parameter 
•VSN' is specified* then the deadstart file will be written to 
tape! otherwise it is written to the file TPXXXK. 

NVESYS requires additional object files for inclusion on 
the deadstart file. These object files contain PP object code 
for the following functions* 

1) Deadstart (file XIDST) 

2) Console/Printer drivers (file XIDSP) 

3) PP helper (file XIHLP) 

4) PP Resident program (file XIRES) 

5) NOS/VE disk drivers supporting multiple 
controllers (files XD4# XD5A# XD5B. XD5C* and 
XD5C2) 

6) NOS/VE MCU Driver (file XMSPMCU) 

7) System Monitor Unit (file XSMUPP) 

8) Nonitor Display Driver (file XMDD) 

9) System Monitor Assistant (file XSMA) 

A copy of the loader directives (file PSYXLDR) will be 
included on the NOS/VE deadstart file (a description of this 
file is Included in a previous section). Also included on the 
deadstart file are the Production System Core Command File 
(DCFILE)# the Recovery System Core Command File (RDCFILE) if 
•REC 1 is specified* and the Configuration Prolog File 
(PROLOG). 
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If any of the above files are not present in the current 
user catalog* they wilt be obtained from the appropriate 
catalog. He. SES»INT2, prefixed procedure calls access 
INT2 level system files onlyt while SES#INT1, prefixed 
procedure calls may access files from either INT2 or INTl 
catalogs as is appropriate for the system being built,) 

The format of the NVESYS is as foil oust 

S£S,NVESYS C vsn * < tape vsn > 3 

C cpf * < Production System Core image file > 3 

C jtf « < production Job Template image file > 3 

i rcpf * < Recovery System Core image file > 3 

C rjtf * < Recovery Job Template image file > 3 

C area * < user name > 1 

C cmds * < tape generator commands file > 3 

C pack 3 

C nocti 3 

C rec 3 

C batch 3 

vsn i The VSN of the tape to be written. This tape 
must be available to the operator. The default 
is to write the file to a disk file as specified 
above, 

cpf * The Production System Core image file. The 
default is PSYXX, 

Jtf i The Production Job Template image file. The 

defaul t is PJBXXYY. 

rcpf t The Recovery System Core image file. The 
default Is RSYXX. 

rjtf » The Recovery Job Template image file. The 
default is RJBXXYY, 



area * The name of the catalog to search for the flies 
needed to build the deadstart tape or file 
should they not be found in the current 
catalog. The default is the <Integr at lon> 
cata I og, 

cmds I The name of the file containing directives for 
use by the deadstart tape generator. The 
default is to use procedure-defined directives. 
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pack i Option to pack the deadstart file for dual 
state* The default is to nal pack the deadstart 
fi le. 

nocti i Option to qq.£, put CTI on the deadstart file. 
The default is to write CTI to the beginning of 
the deadstart file. 

rec * Option to build a Recovery System deadstart 
file. The default is to build a non-Recovery 
System deadstart file. 

batch t Run NVESYS in BATCH mode. The default is to run 
it 1 ocal I y. 

2.9.3 COMPILING 180 PP CODE (CPP130 PROCEDURE) 

CPP180 is an SES procedure file which compiles 180 PP 
code. The source for the P? code is retrieved from a source 
program library. If the *»AB M parameter Is specified* CPP180 
will search this PI first before searching NQSVEPL to satisfy 
externals. NQSVEPL comes from the <lntegr at i on> catalog. 

The format of the CPP180 is as follows? 

SES.CPP180 C m * < module name > 1 

t ab « < alternate base > 3 

C area * < user name > 1 

C listing « keyword or keyword »<tape vsn>l 

I batch ] 

m i The module name of the PP program to be 

comp i I ed. 

ab t The alternate base searched by CPP180 to satisfy 

externals before searching NQSVEPL. The default 
is to search only NOSVEPL. 

listing t To save the compilation listing as a permanent 
file or archive i t to a tape. The default is no 
1 1st ing is saved. 

area t The name of the catalog to search for the PL 

specified by the »A8* parameter should it not be 

found in the current catalog. The default is 
the <Integrat I on> catalog. 

batch t Run CPP180 in BATCH mode. The default is to run 
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i t I ocal I y. 
2.10 aUAL-SIAlE-ERflCimiEIS 

2.10.1 BLDEI PROCEDURE DESCRIPTION 

BLDEI is an S£S procedure file which builds the absolute 
file for dual state EI. The AB parameter may be specified if 
a program library containing the dual state EI source exists 
in the current catalog; otherwise BLDEI retrieves EI from 
NOSVEPL In the <lntegrat ion> catalog. 

BLDEI uses the linker parameter file EILC8 to link EI. If 
this file does not exist in the current catalog* it is 
obtained from the CIntegrat i on> catalog by the procedure. 

The outputs of BLDEI include the direct access absolute 
file 'EI* and the direct access file *DSLIST* which contains 
the assembly listing and the link map for £1. 

The format of the BLDEI is as follows* 

SES. BLDEI t i * < EI source file > 1 

C area * < user name > 1 

t listing * keyword or keyword*<tape vsn> 1 

C batch 1 

i i The file in the current catalog which contains 

the dual state £1 source program library frosi 
which EI is to be built. The default is to get 
the £1 source from NOSVEPL in the <Integr at ion> 
cata 1 og. 

listing t Option to save the compilation listing in a 
permanent file or to archive the listing to a 
tape. The default is no listing is created. 

ab t The user f s alternate base program library 

containing new and modified modules. 

area « Option to obtain the object files or linker 

parameter files from another user f s catalog 
(other than the current catalog In which the 
procedure is executing). 
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2.10.2 BL0170 PROCEDURE DESCRIPTION 

BLD1T0 is an SES procedure file which builds the A170 dual 
state deadstart tape binaries containing the modi f ica ti ons to 
A170 NOS to support dual state. The assembled binaries are 
put on the direct access file SYSBINS. The COMPASS assembly 
listings may be saved either on disk (file DSLIST) or on tape* 
depending upon the specification of the 'LISTING* parameter. 

The format of the 8LD170 is as follows! 

SES.8LD170 t m » < list of module names> 3 

t ab * < alternate base file > 3 

C area * < user name > 3 

C listing J listing » < tape vsn > 3 

C batch 1 

m 1 The module name(s) of the COHPASS routines to be 

assembled. The default is to assemble all of 
the A170 NOS dual state support modifications. 

ab i The user's alternate base program library 

containing new and modified modules. The 
default is NEWDKPL. 

area * Optional catalog specification to add to the 
search list for files needed by 8LD170. The 
default is the current catalog. 

listing i Specifying the keyword 'LISTING 1 saves the 
assembly listings on the direct access file 
DSLIST. Specifying »LISTING»<tape vsn>« writes 
the assembly listings to the tape with the 
specified VSN in sorted order. The default is 
to aflj; save any listings. 

batch t Run BLD170 in BATCH mode. The default is to run 
it I ocal I y. 

2.10.3 8L0ICF7 PROCEDURE DESCRIPTION 

BLDICF7 Is an SES procedure file which builds the 170 
library file LINKLIB. This library contains the binaries for 
the 170 side of the Interstate Communication Facility. The 
SYMPt/COMPASS listings may be saved either on disk (file 
DSLIST) or on tape* depending upon the specification of the 
•LISTING 1 parameter. 
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The format of the BLDICF7 is as fo I Ions' 

SES.BLDICF7 I m * < list of module names> 1 

t ab * < alternate base file > 3 

C area « < user name > 3 

C listing * listing * < tape vsn > 3 

I batch 3 

m » The module namets) of the routines to be 

assemb led/comp I I ed. The default is to assemble 
all of the modules which iriake up the LINKLIB 

I I br ar y. 

ab t The user's alternate base program library 

containing new and modified modules. The 
default is NEMOKPL. 

area * Optional catalog soecl f I cati on to add to the 
search list for files needed by BLDICF7. The 
default is the current catalog, 

listing J Specifying the keyword 'LISTING' saves the 
assembly listings on the direct access file 
DSLIST. Specifying 'LI STING*<taoe vsn>* writes 
the assembly listings to the tape with the 
specified VSN in sorted order. The default is 
to qo.j; save any listings. 

batch * Run 8LDICF7 in BATCH mode. The default is to 
run i t local ly. 



2.10.4 BLDIF7 PROCEDURE DESCRIPTION 

BLDIF7 is an SE S procedure file which builds the A170 
deadstart tape binaries needed to support the NOS/VE 
Interactive and operator Facilities. The linked binary 
absolutes are put on the direct access file SYS8INS. The 
compilation/assembly listings may be saved either on disk 
(file DSLIST) or on tape* depending upon the specification of 
the 'LISTING' parameter. 

The format of the BLDIF7 is as follows! 

SES.8LDIF7 £ ab « < alternate base f i I e > 3 

£ area « < user name > 3 

C debug 3 

£ listing S listing * < tape vsn > 3 

£ batch 3 
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ab * The user's alternate base program library 
containing new and modified modules. The 
default is NEWOKPL. 

area J Optional catalog specification to add to the 
search list for files needed by BLDIF7. The 
default Is the current catalog* 

debug J Option to link Interactive with NETIOD. The 
default is to link with NETIO. 

listing i Specifying the keyword 'LISTING* saves the 
assembly listings on the direct access file 
DSLIST. Specifying *LI STING*<tape >tsf\>* writes 
the assembly listings to the tape with the 
specified VSN in sorted order. The default is 
to nut save any listings. 

batch * Run BIDIF7 In BATCH mode. The default is to run 
it I ocal 1 y. 

2.10.5 3LDRH7 PROCEDURE DESCRIPTION 

810RH7 is an SBS procedure file which comp i I es/ assembl es 
the modules which make up the A170 side of the Remote Host 
Facility and produces the updated RHA170R library file 
containing the A17C relocatable Remote Host binaries. When 
RHA170R has been built* BLDRH7 will link to produce the five 
absolute files which are added to the A170 NOS system 




curreiu uavaiuy. i nc u uihh i i a \. i un / a a> emu i y I Istlngs may be 

saved either on disk (file DSLIST) or on tape* depending upon 
the specification of the 'LISTING* parameter. 

The format of the 8LDRH7 is as follows* 

SES.BLDRH7 t m « < list of module names> 1 

C c * < processor option > ] 

C ab « < alternate base fi le > ] 

C ar ea * < user name > 1 

C listing * listing * < tape mst\ > 1 

£ batch ] 

m i The module name(s) of the Remote Host routines 
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to be compiled/assembled. The default is to 
compile/assemble all of the modules which make 
up A 170 Remote Host, 

c « For a xjfiw. module* the processor option for 

compiling or assembling the module. Specify 
*C»1« for CYBIL CC modules and »C«G» for COMPASS 
modules. The default is *C*1» for D£ii modules* 
and internally defined defaults (stored with the 
module name within the BLDRH7 procedure itself) 
for existing modules. 

ab « The user's alternate base program library 

containing new and modified modules. The 
defaul t is NEWDKPL. 

area t Optional catalog specification to add to the 

search list for files needed by 8LDRH7. The 
default is the current catalog. 

fisting t Specifying the keyword 'LISTING* saves the 
assembly listings on the direct access file 
DSLIST. Specifying «LISTING«<tape vsn>> writes 
the assembly listings to the tape with the 
specified VSN In sorted order. The default is 
to flfil save any listings. 

batch * Run 81DRH7 in BATCH mode. The default Is to run 

it I ocal ly. 



2.10.6 3S3IL0 PROCEDURE DESCRIPTION 

DSBILD Is an SES procedure file which builds the dual state 
binaries XDSTVEt XRUNVE* and XTRMVE. AH assembly and CYBIL 
compilation listings are put on the direct access text library 
file DSLIST Cone listing per record* each headed by the 
corresponding NAOIFY deckname) and the three load maps are 
appended to the compilation and assembly listings* 

The format of the DSBILD is as follows? 

SES.DSBILO t ab « < alternate base > 3 
tarea « < user name > 3 

[listing « keyword or keywor d*<t ape vsn> 3 
C batch 3 

ab i The user f s alternate base program library 

containing new and modified modules. 
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listing t Option to save a compilation listing as a 

permanent file or to archive the listing to a 

tape* The default Is no listing will be 
created, 

area « Option to obtain the PL specified fey the •AS* 

Parameter from another usar*s catalog should It 
not be found in tJie current catalog. 

batch t Run DSBILD in 8ATCH mode. The default is to run 

it I ocal I y. 



2.11 UIILm-£&aC£GUS£$ 



2.11,1 NVEREP - REPORT SYSTEM CONTENT 

NVEREP is a procedure which dynamically produces NQS/VE 
build content reports based upon build information contained 
In the Integration procedure library (PR0CLI8)* or that 
generated dynamically by partner procedures. The reports are 
sorted according to a user suoplied primary sort key, and a 
procedure defined secondary Hey which is associated with the 
Primary sort key. The amount of information contained on the 
Integration procedure library is limited by the SES Command 
Language processor to eighty characters* but the procedure is 
sufficiently generalized to work with expanded Information 
produced by partner procedures. These partner procedures are 
not of a generalized nature so as to be documented at this 
time {primarily due to a series of deficiencies in the current 
CI tools and conventions). 

The format of the NVEREP procedure is as follows: 

SES.NVEREP t left « < primary key > 3 

C right * < primary key> 1 

C area • < alternate user name > 3 

C f * < input source > 3 

C o ■ < output destination > 3 

C 1 * < I i br ar y name > 3 

C print 3 

C batch 3 

left * Primary sort key for left side of two paged 

report. Only the first two characters of this 
parameter are significant. May be either 
MOdule, MAdify* Library* or LAnguage, (An 



for right side of 


two 


paged 


parameter left 


for 


vai id 


Default is HAdify. 
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additional option* VErsion* is only available 
when used in conjunction with partner 
procedures* Option 8U i I d is under consideration 
for future implementation*) The default for 
this parameter is HOdule. No validity checking 
Is performed for either the •left 1 or f right' 
parameter values* and an invalid specification 
will result in a report which may differ from 
that desi red. 

right t Primary sort key 

report. See 
spec if icat Ions. 

area i Alternate user name to search first for the 

input file specified by the • f» parameter. 
Default value is 'null 1 * and source for »f* is 
found in the user name where the procedure 
resides (PRCUNAM). 

f t Name of the file containing build content 
Information. Default is PR0CLI8. 

« Name of the file to receive the two paged 

report. Default is VEREP. (The files LEFT and 
RIGHT currently remain local after the procedure 
has completed. These files contain the left and 
right hand portions of the two paged report.) 

1 t Name(s) of NOS/VE library (or libraries) which 

are to be included in the report. Default is to 
report on ail primary NOS/VE libraries. 

print * Keyword to cause output file to be printed. 

Default is to not print the report unless batch 
execution has been selected. 

batch * Keyword tc cause the batch execution of the 
procedure* Default is to run the procedure in 
'LOCAL* mode. 



2.11.2 PROCEDURE GET - GET A LOCAL FILE 

The GET procedure provides a "working copy" of a file (ie. 
one which can be written to* or read from* without concern as 
to whether the file is accessed as a DIRECT or INDIRECT 
file). Several user catalogs may be searched for the file by 
specifying a list of values for the UN parameter. If a local 
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file already exists with the same name as that specified by 
the LFN or PFN parameters then the local file is either 
rewound or converted to a working file. One message per file 
is issued to indicate the action performed on the filenames 
specified on the procedure call. The MF parameter specifies a 
filename upon which the working files are to be appended. 



The format 


of the GET procedure is as follows* 


ES. GET 


C 1 f n » < local filename > 3 




C pfn * < permanent filename > 3 




C un « < user name > 1 




[ if « < merge filename > 3 




C a J na ] 



Ifn * Local file name by which the file is known (may 
be a list of files). If no filename is 
specified for lfn> then the filename value for 
the PFN parameter is positional ly used* A 
common usage of this procedure is as follows* 
SES.GET <MYFILE1>HYFILE2* ... #etc.) 
In the above procedure call the permanent files 
MYFILElf MYFILE2, etc.* would be made local 
working files named tfYFILEl, MYFILE2, etc. 

pfn * Permanent file name to be made a local working 
file. If no filename is specified for pfn* then 
the value specified for the LFN parameteris 
used. The list of PFN values is matched 
positional ly with the LFN specified values. 
This is illustrated as follows* 
SES.GET (one>two) < stuff 1* stuff2) 
The above procedure call would create working 
files named ONE and TWO from the permanent files 
STUFF1 and STUFF2 respectively. 

un * An optional list of user names to direct the 
search order for files which are currently not 
local. This is convenient if the user knows 
that the file exists in one of several 
catalogs. An example would be* 
SES.GET IPNDOC UN«( i ntl* in t2,devl, dev2* r e 1 1 ) 
The above procedure cat! would search local 
files for a file named IPNDOC followed by the 
catalogs INT1# INT2# etc. until the file is 
found or the search is exhausted. 

mf * A filename upon which to stack the resultant 
working files. For example* 
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SES.GET ClPNDOCfBCR) MF*BUILD0C 

The above procedure call gets the files IPNDOC 
arid SCR as working files* then appends them to 
the file 3UILD0C. IPNDOC and BCR remain as 
working files along with 8UILD0C. 

na * » Keyword which determines whether the procedure 
should abort in FILE NOT FOUND situations. 
Default is to REVERT* ABORT . 



2.11.3 PROCEDURE SAVE - MAKE A LOCAL FILE PERMANENT 

Procedure SAVE may be used in conjunction with the GET 
procedure, The redeeming factor about the SAVE procedure is 
that the user need not be concerned about file size. The 
named local files are made permanent as INDIRECT access files* 
if possible* otherwise DIRECT access files. This is 
Intentionally done to preserve as much Precious disk space as 
possible* (NOS allocates DIRECT access files much less 
frugally than INDIRECT access files.) Be forewarned that a 
slight penalty is imposed in access time for each sector of 
disk space saved in this manner* and that the actual sector 
savings is only visible from the operator's console (not via 
CATLIST). In the procedure writer's world of living* this 
procedure negates the worry of predicting file size prior to 
creating it. Files arc SAVE'd as S EMI-PRIVAT E READ-ONLY 
files* unless changed via the CT and M parameter or profile 
varl able values* 

The format of the SAVE procedure is as follows: 

SES.SAVE C Ifn » < local filename > 3 

I pfn * < permanent filename > 3 
C ct • < catalog type > 3 
t m « < access mode > 3 
C di r 3 
C a * na 3 

Ifn t Local filename to be made permanent. Defaults 

to PFN value if not specified. Parameters may 
be specified oos 1 1 i onal ly* and typical usage is 
as f oi lows: 

SES.SAVE <xlmmtr*xl jl ib* ... *etc.) 
In the above procedure call the files 
XLMTR*XLJLIB* etc. are SAVEd as permanent 
files. A message is issued to indicate the type 
of file created (DIRECT or INDIRECT). 
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pfn J 



ct * 



permanent filename for files to be saved. 
Defaults to LFN If not specified. PFN values 
are matched posltlonally within the list to LFN 
values* This is illustrated as follows! 
SES.SAVE <one*two> ( stuf fl#stuff 2 > 
The above procedure call saves files ONE and TWO 
as permanent files named STUFF1 and STUFF2. 

Catalog Type of the file when made permanent. 
Default is to make files semi-private (CT»S). 



m i 



Mode of the file when accessed* 
access <M*R). 



Default is read 



dlr * 



Keyword which directs the procecure to make all 
named files DIRECT access files* regardless of 
thei r size* 



a * n 



Keyword 


wh ich 


shou 1 d 


abort 


Def aul t 


is to 



determines whether 
if FILE IS NOT 
REVERT. A30RT* 



the procedure 
A LOCAL FILE. 



2.11.4 NVEMAP - REFORMAT NOS/VE LINKMAP 

MVEMAP is a procedure to reduce the number of printed pages 
of a NOS/VE linkmap* while maintaining readability* and to 
Provide summary reports of information contained wihtln the 
linkmap* Either all* or portions of the linkmap may be 
processed* The reformatted form of the linkmap is also 
suitable for microfiche* in the format defined for the NOS/VE 
operating system. 

The format of the NVEMAP procedure is as follows* 



SES. NVEMAP 



i « < input fi I e > 
o » < output f i I e> 
area ■ < alternate 



copy * < 
sk i p ■ < 
pr int 3 
gated 3 
fi che 3 
module 3 
sav e 3 
two 3 
batch 3 



record 
recor d 



3 

1 

use r 
count > 
count 



name > 
3 



> 3 



I t 



Input file which contains generated output from 
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the execution of the NOS/VE CI (or SES) Linker, 
Default is flAPXX for the system. 

o i Name of the output file to receive the 
reformatted linkmap file* Default is to produce 
a local file of the same name as specified by 
the • i • parameter • 

area t Alternate user name to search for the input file 
specified by the f i f parameter. Default value 
is •null 1 . 

copy t Count of the number of NOS records to process 

from the current file position of the input file 
(default position B0I) • Each invocation of the 
linker produces a new record upon the output 
file. Thus* to process only the first portion 
of the linkmap (typically Monitor for the NOS/VE 
Operating System) •C0PY»1« would be specified. 
Default value for this parameter is to process 
the entire linkmaP 801 to EOI. 

skip i Count of the number of NOS records to skip prior 

to processing. For the NOS/VE operating system 
, SKIP*2 I would suppress the Monitor and £1 
portions of a Dual State linkmap. , SKIP*2 
CoPY'l 1 would process only the Task Services 
portion of a Dual State linkmap. Use of either 
the •skip' or 'copy 1 parameters infers explicit 
knowledge of the content the linkmap. Due the 
the number of variations of linkmap which can be 
produced it would be impractical to generalize 
these parameters in a more logical manner. 

print i Keyword to cause output file to be printed. 
Default is to not Print the reformatted 
linkmap. •PRINT-TW0MAP 1 will print the contents 
of file named TW0HAP. Key 'PRINT* will print 
TWQHAP if key »TW0 f is also specified* otherwise 
the file specified by the • o 1 parameter will be 
printed. »PRINT*ALl l will print both TW0NAP and 
the file specified by the »o« parameter. 

gated i Keyword which eliminates information for all 
entry points which do not have the GATED 
attribute. Conceivably* a combination such as 
•SKIP-2 C0PY»1 GATED* would produce information 
to a compiler project about which entry points 
within Task Services are GATED for their use. 
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Default is to produce reports of alt system 
entry points. 

f i che t Directs the procedure to place the output of the 

Procedure onto the file NQSLIST for subsequent 
microfiche processing. Default is to not add 
the linkmap to the NOSLIST file. 

module * Keyword which causes the removal of all entry 
point information from the linkmap. This proves 
useful for auditing module attributes. The 
default is to retain all system entry point 
inf ormatl on. 

save s Keyword which causes the output files to be 
retained on permanent files for subsequent 
inspection. It Is left to the discretion of the 
user to dispose of local copies of the output 
files. 

two « Keyword which directs the procedure to twopage 
the linkmap onto the file TyOHAP. TWOHAP will 
always be generated* but will only contain the 
summary report information unless *two* is 
specified. This twopage option Is not the 
familiar SES TWOPAGE option* but rather a 
computed split and merge of the reformatted 
map. 

batch i Keyword to cause the batch execution of the 
procedure. Default is to run the procedure in 
•LOCAL 1 mode. 

This procedure will always produce two output files. The 
primary output file is governed by the •o* parameter. A 
secondary output *TW0MAP» is always produced as well. The 
•TWOflAP' file will only contain the summary reports and 
loadmap if parameter •two 1 Is not selected. The first summary 
report which is produced is a two paged report of PVAs found 
In the linkmap. The left hand portion of this report Is a 
sort by PVA. The right hand portion of this report is a sort 
by module and/or entry point name. This report should answer 
the questions: 1. Given a PVA* in which module and/or 
procedure is that PVA contained?* 2. Given an entry point 
name* in which module is it defined and what is its PVA?* and 
3. Given the name of a variable within a system defined 
table* what Is its location within a dump? 

The final report is a two part error summary for the 
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Hnkmap. The first portion of this report identifies which 
pages of the linkmap contained one or rcore errors. The second 
portion of this report is a iist of all of the errors found 
within the linkmap* in the sequence in which they appear in 
the map. 
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2«11.5 PROCEDURE FORMPRoC - FORMAT PROCEDURE 

This procedure reformats a single SES or CCL procedure 
which is present on a GROUP file. Nesting levels of the 
procedure are used to compute a floating margin to Indent 
statements contained within If, IFE, WHILE, ROUT, or SKIP 
bl ocks. 

The first TOKEN of each line is processed as follows* 

- IF a double quote (") then leave the line asls. 

IF a backward slant <\) then process the second TOKEN. 

- IF a blank and DELETE boolean FALSE* then leave asis. 

- IF AND or OR, then this line is continuation of SES IF or 
QRIF, adjust margins appropriately if INROUT boolean is 
FALSE. 

- IF a CCL IFE, WHILE, SKIP, etc. and CCL boolean TRUE then 
adjust margins, and add blank lines as appropriate* 

- IF none of the above, or a ROUT - RQUTEND block and D0R0UT 
boolean is false, then leave line asis. 

The second TOKEN, for lines having backward slant as their 
first TOKEN, is processed as follows* 

- IF a valid SES reserved name, then uppercase the TOKEN and 
adjust margins as appropriate. 

- IF not a valid SES reserved name, then GENLOWR the TOKEN 
and SU3STR the value to a seven character value. (This is 
typically a statement assigning a value to a SES 
varl abl e.) 

Conventions for spacing and indentation were established 
through trial and error with several complex procedures. Most 
all of the values which govern these conventions have been 
externalized as parameters and PROFILE variables to allow 
tailoring to individual tastes* Blank lines are used to 
signify the start or end of a IF, ROUT, WHILE, or SKIP block 
or to highlight the presence of INCLUDE, CYCLE, ACCEPT, or 
EXIT statements. 

Special limitations are imposed upon procedures formatted 
by this procedure. If the formatted length of a statement 
exceeds 79 characters (a SES restriction) then a terse 
diagnostic Is issued and the line is left unformatted. Each 
diagnostic or message issued indicates the line number being 
processed as well as the line number being written. Thus, the 
growth or shrinkage of a procedure can be observed while 
formatting is taking place. Informative messages are issued 
to indicate when a new indentation "nest" level has been 
reached. These Informative messages are Intended to give the 
warm feeling that the procedure is doing something. 
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2.11.5 PROCEDURE FORHPROC -^FORfJAT maCEDURE 

The format of the FORMPROC procedure Is as follows* 

SES.FORHPRGC C I « < filename > 1 

[ o * < fl lename > 3 

C control ■ < str ing > 1 

t indent * < number > 1 

C after ■ < number > 3 

t blanks * < boolean > 3 

t de lete * < boo I ean > 3 

C ccl « < boolean > 3 

C dorout • < boolean > 3 



I t Input filename containing the procedure file 

source. Default name is GROUP. 
o « Output filename to which formatted procedure is 

to be written. Default Is GROUP. 
control i A string which defines the SES directive 

character for the procedure to be formatted. 

Default is \ (backwards slash), *»commerci al at w 

character cannot be used, 
indent * Number of spaces to indent from left margin. 

Default value is two spaces (for unnested SES 

directives column 1 contains f \» and column 2 

contains a blank character* for CCL IF* WHILE* 

or SKIP commands columns 1 and 2 contain blanks 

if the CCL boolean is TRUE), 
after i Number of spaces to indent lines occurring after 

IF* WHILE* ROUT or SKIP statements. Default 

value is two spaces. 
blanks J Boolean which if TRUE causes the insertion of 

blank lines into the formatted procedure (if 

needed). Default is TRUE. 
delete t Boolean which If TRUE causes the deletion of all 

unneccessary blank lines. Default is FALSE. 
ccl i Boolean which if TRUE causes CCL (including NCS 

Command Language Statements) to be indented 

along with other procedure statements. Default 

is TRUE, 
dorout t Boolean which if TRUE causes ROUT - ROUTEND 

statements other than SES directives to be 

formatted. Default is FALSE. WARNING!!! A 

TRUE value for this parameter can create havoc 

with HELP documentation. 

Note* When formatting procedures which contain only CCL 
statements It Is recommended that INDENT«0 and BLANKS«FALSE be 
specified. 
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2.11.6 PROCEDURE SIZES - REPORT NODULE SIZES 

This procedure uses partner procedures NVEMAP and HEXTDEC 
to produce a "quick and dirty" report of module sizes In 
decimal and hexadecimal byte lengths from a VELINK link map. 
Very little sophistication has been worked into this procedure 
whose purpose is to provide data for the Maintenance Task 
Force in their analysis of Remote Maintenance techniques in a 
Binary Release environment. 

The format of the SIZES procedure Is as follows' 

SES. SIZES C i « < filename > 3 

C o * < f i lename > 3 
t un » < user name > 3 



i i Input filename containing a VELINK link map. 

This parameter is required, 
o t Output filename to write report to. Default is 

same as input filename, 
un i User name in which input file is to be found. 

Default is current user's catalog. 



2.12 E&£;=I!iI££&AIiaH_fiyiiD.S 

During the Build timeframe* a small group of people 
consisting of 3 developers and 1 integrator formed the 
Pre— Integra tion Build Team. The purpose of this group is to 
ease and expedite the formal build process by turning around 
problems and generating fixes before a formal Integration 
build Is performed* When a major feature* requiring a great 
deal of code and causing substantial impact upon the system* 
is ready for Integration* the Pr e-Integr at ion Build Team goes 
to work on It first. The code is applied to the PL's In the 
Integration catalog (INTD* and the entire system is compiled 
£Jiifi&l2 in the pr e-i ntegr at i on build catalog. Modsets are 
generated by this group to correct any compilation errors* the 
system is linked and a deadstart tape is built for testing on 
the hardware. The regression tests are run on this system* 
and fixes are generated to solve problems found. When the 
Pre— Integration Build Team has fixed as many problems as it 
can or needs to* Integration makes its formal build in the 
Integration (INTD catalog with the original code plus fixes. 

In order to build the entire system in a timely manner* 
pre-i ntegr at ion build procedures have been developed and are 
outlined In the following sections. 
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2*12,1 GENDEK PROCEDURE DESCRIPTION 

The GENDEK Procedure takes the latest list of deck names of 
each of the OS libraries from the Integration PR0CLI8 (i.e. 
LMMTR* LS113# LJ23o» etc.). and creates two files of MADIFY 
directives - one file (the last 4 characters of the library 
file appended to the string 'AOK') contains a *EDIT directive 
for each assembler deck* and the other file (the last 4 
characters of the library file appended to the string »CDK f ) 
contains a *£DIT directive for each CYBIL deck. If a 
particular library does not contain any assembler decks (or 
any CYBIL decks)* GENDEK will issue an informative message 

stating as much* and no ADK (CDK ) file will be 

created. The ADK ./CDK files will be saved in the 

current catalog for a subsequent 8IL0LI3 run. 

The format of the GENDEK Is as follows* 

SES. GENDEK 



2.12.2 8ILDLI8 PROCEDURE DESCRIPTION 

The BILDLIB procedure takes the ADK and CDK files 

Cif they exist) for a particular library (created by GENDEK)* 
and assembles/compiles ail the modules for that library. For 

each assembler deck on the ADK file a separate call to the 

C180 assembler Is performed* and the packed assembled binaries 

are copied to the library file. The CDK„ file is used to 

make one call to MADIFY to write all CYBIL modules to one 
compile filet which in turn is fed to CYBIL. The CYBIL 
binaries are copied to the library file following the 
assembler binaries* and the library file is saved in the 
current catalog. &£ compilation listings are produced. The 
dayfile for the job is saved in the current catalog (the last 
4 characters of the library name ^appended to the string f DAY f ) 
for input to the CHKLIB procedure* The GENDEK procedure ffiysi 
be run prior to a BILDLIB run. 

The format of the BILDLIB is as follows* 

SES. BILDLIB t lib « < library indicator > 3 

C plu • < user name > 1 

C b « < PL name > 3 

I ab » < alternate base > 3 

C abu « < alternate base user name > 1 

t local 3 

Mb t The last 4 characters of the name of the library 
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to be built. This parameter Is ££;3iiJxe.jj. 

plu i The naie of the catalog to search for the PL's 

and the compiler. The default Is the 

<Integrat I on> catalog. 

b i The name of a PL In the current catalog to 

include in the MAQIFY PL search list. This 
parameter is optional. 

ab » The name of a PL In another user's catalog to 

include in the MADIFY PL search list. This 
parameter is optional. 

abu t The name of the catalog to search for the PL 

specified by the •AS 1 parameter. This parameter 
Is required if the •AS 1 parameter is specified 
and Ignored if the 'AB' parameter Is qq£ 
spec! f i ed. 

local * Run 8ILDLIB locally. The default is to run It 

in BATCH mode. 

flfJIE* The modules RHHSINTERIH.SI^UL ATED_I0 <deck RHMSIO in 
library XLJ23D) and QCmOMC_SimjLAT£D_ I0_R0UTINE5 (deck OCHCIO 
in library XLJ38B) Mill aluais have compilation errors* Both 
modules require common decks from CYBICMN* but including 
CYBIC^N in the MADIFY PL search list for these two libraries 
causes many &£££ compilation errors in other modules. 
Currently* these two modules must be rebuilt* a£ts£ running 
8ILDLI8 for their respective libraries* using the procedure 
NVEBILD (see the documentation for this procedure in a 
previous section). 



2.12.3 SILOALL PROCEDURE DESCRIPTION 

The BILDALL procedure simply submits a batch BILDLIB run 
for each of the OS libraries. 

The format of the BILDALL Is as follows! 

SES. BILDALL C plu « < user name > 1 

C b • < PI name > 1 

C ab « < alternate base > 1 

t abu « < alternate base user name > 1 

t batch 3 

plu t The name of the catalog to search for the PL's 
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and the compiler • The default Is the 
<Integrat ion> catalog* 

b » The name of a PL in the current catalog to 
Include in the HADIFY PL search list. This 
Parameter is optional. 

ab * The name of a PL in another user»s catalog to 
include in the MA9IFY PL search list. This 
parameter Is optional. 

abu i The name of the catalog to search for the PL 
specified by the f AB* parameter. This parameter 
is required If the f AB* parameter Is specified 
and ignored if the *A3 f parameter is qg.1 
specif led. 

batch t Run BILDALL In BATCH mode. The default is to 
run i t local ty • 



2.12.4 CHKLIB PROCEDURE DESCRIPTION 

The CHKLIB procedure uses the dayfile saved from a BILDLIB 

run C *DAY„ • file* see BILDLIB description) to report any 

MADIFY/assembler/CYBIL errors. It simply uses XEDIT to 
extract the necessary information* which is displayed on the 
file 'OUTPUT*. 

Th* format of the CHKLIB is as follows* 

SES. CHKLIB C lib « < library indicator > 3 
C batch ] 

lib * The last 4 characters of the name of the library 
which was built. This parameter Is r.e.au,J.L£JS« 

batch « Run CHKLIB in BATCH mode. The default is to run 
it locally. 



2.12.5 PURDEK PROCEDURE DESCRIPTION 

The PURDEK procedure simply purges all the ADK _* 

CDK__ # and DAY files from the current catalog at the end 

of a preH ntegrati on when they are no longer needed. 

The format of the PURDEK is as follows* 
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SES.PJRDEK 
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3.0 DUAL STATE INSTALLATION SEQUENCE 



3.0 0UAL^IAI£-I*tf IAUALIJMLi£flli£flC£ 



This section describes how to install all of the files 
needed to run NOS/VE in Dual State mode. To do this from 
"scratch" the following materials are necessary* 

1 HSL tape 

1 Dual State NOS Deadstart tape 

—The LOADPF tape(s) which contain the NOS/VE environment 



If NSL and CTI are already present and correct* then It is 
only necessary to install a new deadstart sector on disk or to 
load a new NOS/VE environment. 



3.1 a£L£Aa£-EEim£a.iEAC£-AHfl-LliSIAU-CII 



UA&ttIiifi=— IhLs, ££Ji££s&-. .sJutuld— anl* fce.__da.n£_fc*-iiis-si££ 

To release reserved disk space* deadstart from the Dual 
State NOS Deadstart tape which is NT# D»PE> F*I> L8*KU» and 
enter* 

U for the Util ities display 
I for Install CTI to disk 

-This display will appears 

ENTER ONE OF THE FOLLOWING 

<CIO - INSTALL DEADSTART NODULE ON DISK 

R - RELEASE CTI-HSL/HIVS RESERVED DISK SPACE 

Enter R and this display will appear* 

RELEASE CTI-MSL/HIVS 
RESERVED OISK SPACE 

Enter the disk parameters as they are requested. 

CH 00 
EQ 00 
UM 00 
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3.1 RELEASE RESERVED SPACE AND INSTALL CTI 



-This display will appear: 

ENTRY OF CR WILL CAUSE RELEASE OF 
CTI-NSL/HIVS RESERVED DISK SPACE 

Enter a carriage return and RELEASE COMPLETE* CCR) TO 
PROCESS DIFFERENT DEVICE Mill appear. Enter a carriage 
return. 

-The ENTER ONE OF THE FOLLOWING display will appear again? 
this tine enter a carriage return* A WARNING message will 
appear! enter another carriage return. 

This display wilt appear: 

INSTALL DISK DEADSTART MODULE 

Enter the disk parameters as above. The following messages 
Hi i I appear * 

INSTALLING CTI TO DISK 

INSTALL COMPLETE. 



3.2 I&HALLJSS1 

-Deadstart from the MSL tape (CTI Is on the tape also.) From 
the *A* display, type in U for Utilities. From the *U* 
display, type in T for INSTALL HSL/HIVS TO RMS. 

-This display will appear: 
TDX 

DISK AND TAPE TRANSFER UTILITY 
CR TO CONTINUE 

Enter a carriage return and enter disk and tape parameters 
as they are requested. These parameters are for the disk to 
which HSL is to be loaded and the tape from which it is to be 
loaded. 

DISK CH 01 
DISK UN 00 

TAPE TYPE 03 

0«60X, 1-65X, 2-66X, 3*67X 

TAPE CH 13 
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3.2 INSTALL MSL 

TAPE EQ 00 

TAPE UN 00 

-This display will appears 

A-BUILD MSL FROM TAPE 
B-BUILD C8 LIBRARY ON MSL 
C-ADD PROSS. TO MSL 
D-ADD CB-S TO MSL 
E-COPY PROGS. TO TAPE 
F-COPY CB-S TO TAPE 
G-DIS SYS T8LS 

Enter A and the following display will appear! 

MSL INSTALLATION OPTION 

A«HIVS 

B-MSL/OS SHARED 

C-MSL/MAINTENANCE ONLY 

Enter B. 

-This display will appear? 

HAS A COMMAND BUFFER LIBRARY BEEN BUILT AT 
STARTING CYL 1420 THAT YOU WANT TO SAVE 
Y-Y£S#N*NO 

Enter Nt and the screen will show CHECKING STARTING 
CYLINDER* BUILDING SRT, and BUILDING PNT. 

The next displays and corresponding entries are? 

COPY FROM 

-CR- * FIRST NAME 

Enter a carriage return. 

CTI ON TAPE (Y/N) 

Enter Y 

COPY THRU 

-CR- « LAST NAME 

Enter a carriage return. 



3-4 
ADVANCED SYSTEMS INTEGRATION PROCEDURES NOTEBOOK - Cycle 3 

05/22/82 

m mm m mmm m mmm mmm m mm m m mm mm mmm m mm m m mmm m m m mmm m mm m m mm mm mmmmmmmmmmmmmmmmmmi 

3*0 DUAL STATE INSTALLATION SEQUENCE 
3,2 INSTALL *SL 

m mm m mmm m mmm mm mmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm, 

DATA VERIFY <Y/N) 

Enter N 

-The HSL Tape will load at this point and this display will 
appears 

LAST USED 

CYL Unn TRK 0000 SEC 0000m 

3.3 CflBQKKJaAMfifiS-Afia-CaaSl-EIkE 



3.3.1 N0S CHRDECK AND LIBDECK CHANGES 



When deadstartlng N0S to run a dual state environment* 
It Is required that one or more of the following 
commands be processed by the N0S CMRDECK command 
processor* The command(s) which must be specified by 
the operator will be dictated by the type of N0S 
environment which is to be supported during dual state 
op er at ion* 

NINCM*xxxxx. The parameter 'xxxxx* defines 

the mlnumum amount of central 
memory words which N0S will use 
for the following operating 
system execution* The parameter 
Is an octal value expressed in 
multiples of 100. If this 
command is not specified the 
system assumes a default of 
300.000(8) or 98K(10) central 
memory words* 

VE. This command establishes a Dual 

State Communication Block (DSC8) 
in N0S Central flemory Resident 
<CMR). The DSC 8 is required to 
enable the operator to deadstart 
N0S/VE. 

VE«xxxxx. This command establishes a DSC8 

In N0S CMR and also reserves* 
for use by NQS/VE* the number of 
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3.0 DUAL STATE INSTALLATION SEQUENCE 
3.3,1 NOS CMROECK AND LI8DECK CHANGES 



central memory words expressed 
by the par ameter * xxxxx • • The 
parameter must be an even number 
and Is an octal value expressed 
In multiples of 1000. 

E0xx«D£#ST,0P> SZ*FD.This command Is required if UEM 

(soft ECS) is to be used by 
N0S. The SI parameter Is en 
octal value (minimum of 10) 
expressed in multiples of lCOC. 
The remaining parameters are 
defined In the N0S Installation 
Handbook. NOTE* If this command 
is specified in the N0S CmRDECK* 
it is mandatory that the 
VE*xxxxx* command be specified 
if NOS/VE will be deadstarted. 

The algorithm used by NQS to determine if the memory 
size parameters specified by these commands are * legal* 
1st 

(Machine Field Length) >« (MINCM + UEM + N0S/VE) 

Some examples of hon to use these commands when 
deads tar ting N0S for execution In a dual state 
environment are as follows* assuming a 16MB mainframe* 

VS. No UEM and the default 

MINCM *#i»| be used. NOS 
will allow NOS/VE to use 
all but 98K or 300*000(8) 
words of the machine field 
length* 

VE. No UEM and NOS will allow 

MlNCM-10000. NOS/VE to use all but 262K 

or 1*000*000(8) words of 
the machine field length. 

VS-5000. No UEM and NOS will allow 

NOS/VE to use a maximum of 
10MB or 5*000*000(8) words 
of the mach ine field 

length. NOS will use 6M8. 

VE»5000. NOS will allow NOS/VE to 

EQ5»DE#ST,0P*2C00*FD. use a maximum of 10MB or 
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5,000,000(8) words of the 
machine field length. NOS 
Mi I I all ocate 4H8 or 
2,000,000(8) words for UE* 
and will use 2M8 cr 
1,000,000(8) words for CM. 

b* All CH» lines should be deleted as all memory allocation 
is dynamic. 

c. All N0S/VE mass storage devices must be specified in the 
NOS CMRDECK as DOWN devices, e.g. 
EQnn*DQ-l,00WN #0,40,2. 

d. The disk controlware that NOS loads to FM type 
controllers at deadstart is the correct controlware for 
the N0S/VE 7155-lx disk controllers. Add the following 
line to the CmRDECK to cause controlware to be loaded to 
both the NOS and N0S/VE disk controllers? 
L8CFM,chl,ch2,ch3* (The chi are disk channels as 
appr opri ate. ) 

e* The NOS LIBDECK must be modified to include the new 

procedures necessary for deadstart. *PRGC SETVE and 

*PR0C 0PERFAC must be added and +PR0C UPHYVE should be 
deleted. 



3.3.2 CMDS1 FILE 



a. A feature has been added to Cycle 3 to Improve the 
transportability of the DSTVE directive file CMDS1. If 
*NE«0RY«0. is entered in CflDSl, DSTVE will always 
request all available memory from A170 NOS. It is 
essential with this feature to enter In the NOS CHRDECK 
the entry MINCM«10000. to prevent NOS from giving 
N1S/VE so much memory that A170 NOS will not run well. 



b. The default value for the N0S/VE system device disk 
channel is specified on the following command in the 
CMDS1 file: 
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*SYST>D$PANEL*OFFF0Q<16>«c. 

This means that it Is no longer necessary to 
rebuild IOPQUER to connect the NOS/VE disk to 
the proper channel. 

c. The default value for the NOS/VE deadstart command file 
number (DCF) is specified on the following command in 
the CMDS1 f i let 

*S YST*DS PANEL *CFFFFF( 16 )«n. 

d. The channel number x in the following command should be 
an empty channel i *RELOADCH»x. 

e» Debug flag number 2 should be TRUE to enable recovery to 
work automatical I y* e.g. *5YST> DEBUg2»TrUE. 

3.4 IMSIALL-SmEa 

Deadstart from the NOS Dual State deadstart tape* using the 
deadstart tape which is to be installed. Choose the f f 
option on the first display* for operator intervention. 
Optionally* the «p» display may be selected to choose a 
CMRDECK. (CMRDC14 contains the CANCDD S2 configuration* 
CMRDCK6 contains the ARHOPS S2 configuration.) Hit carriage 
return. The system will display! 

ENTER LOCATION 

OF NSL/HIVS DEVICE 

Enter the information for the same disk where HSL was 
installed previously! 

Channe 1 «xx 
Equi pment«xx 
Uni t»xx 

After the system is deadstarted* enter the following 
commands * 

X.DIS. 

COMIiON*SYSTE«. 
INSTALL*SYSTEM*EQxx. 
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NOTE? xx Is the EST ordinal of the disk where the deadstart 
sector Is to be Installed! this is the same disk where HSL was 
installed previously. 

3.5 L0AQ££-EIi££ 

The LOADPF tapes* which are NT* D = PE* F»SI* and LB»KL* 

contain the NOS/VE operating system source and binaries* tools 

to assemble and link the operating system* and various other 
files. 

Deadstart from the disk upon which the NOS Dual State 

system was installed and LOADPF the files to the desired user 
number. 



3.6 MILLIE JHIAL-Snifc 

Refer to the current Helpful Hints document* Section 4* for 
information regarding the operation and execution of NOS/VE* 
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4.0 tiaSZl£-UASMAa£-B£fiB£SSIQll-I£SIIlifi 



4 .1 imaauciiaii 

The verification currently performed on NQS/VE systems 
consists of running the S2 Regression Test Sequence* as 
outlined in the following sections* on the hardware* 

4 . 2 £*_B£SB£SSIfl!LI£SIS 



4.2.1 JQB2 

J0B2 is a file containing the NOS/VE commands which stage 
an II library and a CI user job object file from the 170 side 
to the 180 si de* convert the CI user job object file to an II 
object file* and then load and execute this user job with the 
library* It then stages the LOAQMAP back to the 170 side to 
be printed. JOB2 tests the following NOS/VE features: 

LINK_US£R command 

SET OBJECT.LIST command 

SeOrOGRAHJJPTIONS command 

GETPF 856 

GETPF B60 

CITOH conversion 

Load/Execute User Program ♦ Library 

JNROUTE C180 print f I le 

SUBMIT of batch job 

JMEXIT 

The command sequence follows: 



LOGIN USER«D€V1 NAME«J0B2 

LIU* USER* (DEV1*NVE)*PA«DEV1X.A*N0TUSED* PR-NOTUSED 

GET*MEWII8RARY*CYBIILB,#D£V1»NVE.3 56 

S6T_39J£CT_LIST,ADD*N£WLI8RARY 

S£T_PR0GRAN_0PTI0NS* LCAOM AP. . . . 

MOM BLOC K*£NTRY_POINT*XREF* SEGMENT) *..* 

TERNINATI0N_ERR0RJ.£VEL«FATAL 

GgT*XPETEST*XPETEST**D£Vl*NV£,8 60 
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EXECUTE, »*XPSTEST,LGO*ftfCITOII 

EXECUTE LGO 

JMROUTE#NOTU$ED,LOADMAP#PR 

SET_QBJ£CT_LIST> DELETE- ALL 

G£T,CY8ILIB#CYBIILB,#D£VlfNVE,856 

SET_PR0GRA*L.0PTI0NS LIST1 TERMINATION_£RROR_LEVEL«ERRQR 

EXECUTE LGO 

JMRGUTEfNOTUS£D#LISTl,PR 

G£T#J0B3,J0B3^tNVEf A6 

SU8HIT,J083 

GET#J0B4fJ0B4##,NVE,A6 

SU8NITtJ0B4 

JHEXIT 



4.2.2 J083 

J0B3 is the same NOS/VE procedure file as J082 and tests 
the same NOS/VE features **lth one addition! instead of doing a 
GET of the II version of CYSILI8 from the 170* J0B3 does a 
NOS/VE permanent file ATTACH of CY8ILI8 from the SSYSTEH 
cata I og. 

The command sequence follows: 



LOGIN USER*D£V1 NAME*J0B3 

LIU»USER*<DEVl,NVE),PA»D£VlX,A«NOTUSgD,PR«NOTUS£D 

ATTACH SSYSTEH.CYBILIB N£ WLISR ARY, . . . 

ACCESS_H0DE«< RE AD# EXECUTE) 

SETJJBJECT.UST* ADD«NEWLIBRAR Y 

SET_PR0GRAM_0PTI0NS>L0ADMAP,... 

H0« < BLOC K,ENTRY_POINT#XREF, SEGMENT),... 

TERHINATION.ERROR LEVEL-FATAL 

GET,XPETEST#XPETEST#,DEV1,NVE>860 

EXECUTE *,»XPETiST#LG0*,,#CIT0I I 

EXECUTE LGO 

JMROUTEfNOTUSEDfLOADMAPf PR 

SETJ3BJECT_LIST,DELETE«ALL 

RETURN NEWLIBRARY 

ATTACH SSYSTEH.CYBILIB ACCSSS_H0D£» (READ, EXECUTE) 

SETJ>R0GRAM_0PTI0NS LISTl TERH INAT I0N_ERR0R_LEVEL»ERR0R 

EXECUTE IGO 

JMR0UTE»N0TUSE0*LISTlfPR 

SET,TESTBA?1/T£STBAH,##NVE,A6 

SU8MIT,TESTBAN 

JNEXIT 
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4,2.3 J084 

J0B4 Is a file containing the NOS/VE commands which execute 
the NOS/VE SETUP command to set up the 180 job environment 
(see Appendix D for the description of the SETUP eommand)# 
followed by a CITOII conversion of a 170 object file user 
program and an EXECUTE of this program. The loadmap is staged 
back to the 170 side to be printed. J0B4 tests the following 
NOS/VE features* 

CONNECT.FILE command 

SETUP command 

CITOII conversion 

SETJ»R0GRAH_0PTIQNS command 

Load/Execute User Program + Library 

JMR0UTE C180 print file 

J1EXIT 

The command sequence follows* 



LOGIN USER»D£V1 NAHE-J034 

CONNECT.FILE $£CH0 OUTPUT 

SETUP DEVI DEV1X 

CITOII II-LG0 CI»XPETEST USER'OEVl 

SET.PROGRA^LOPTIONS LIST1 TERMINATI0N.ERR0R.LEVEL-ERR0R 

EXECUTE LG0 

JHR0UTE»N0TUSED,LIST1*PR 

JHEXIT 



4.2.4 TEST8AN 

TESTBAN is a file containing the statements necessary to 
execute all of the BAH test cases supplied by the 8AH 
project. These procedures exercise various portions of the 
basic access method* and are used to show some level of 
confidence that BAM works as well as it has previously. 

The command sequence follows* 



LOGIN USER-DEV1 NAHE-TEST8AN 

LIU»USER»<DEV1,NVE),PA»Q£V1X,A*N0TUS£D>PR«N0TUSED 

COUECT.TEXT BAMINP 

TES1 

TES2 

TES3 

TES4 

TES5 
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TES6 

TEST 

TES8 

TES9 

TES10 

TES11 

TE512 

TES13 

TES14 

TES15 

TES16 

TES20 

TES21 

TES22 

TES23 

TES24 

TES25 

TES26 

TES27 

T E S 2 8 

TES29 

TES31 

TES32 

TES33 

TES34 

TES35 

TES36 

TES37 

TES38 

BAMSTOP 

** 

ATTACH SSYSTEM.SYSLIB SYSUS ACCESS M0DE»t READ* EXECUTE) 

ATTACH SSYSTE1.CYBILIB CYBILI8 ACCE SS_H0DE«<R£AD> EXECUTE) 

SET 08JECT_tIST ADD- (SYSL 18* CYBILIS ) 

EXECUTE >**BAMINP****8AMTE ST 

GET*SCL180*SCU8G***NV£*A6 

SUBMIT»SCL180 

JNEXIT 

V.3 £2_a££&£iU2M-I£SI-££flU£a££ 

1) Deadstart A170 NOS? 

Set the deadstart pane! to disk deadstart from* 
CH-1 
UNIT-41 
WORD 13«0006 
Push deadstart button. 
- Select *0* display. 
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Hit carriage return. 

- Enter date/time, 

2) If necessary, update the INT2(9EV2) catalog and load 
the latest system files into the INTKDEV1) catalog* 

- Hount the INTKDEV1) and INT2(DEV2) catalog QUMPPF 
tapes* 

- X.DIS* 

USER, INT1 (DEVI)* INTK DEVI) X. 
SES.UPCATS <WC»tPul> <SC»tpu2> <SYSEDIT> 
Hit w , w to go into AUTO mode. 
DROP, 
The SES.UPCATS procedure *orks as follows* 

a. Updates the INT2(DEV2) catalog by 
retrieving 0SLI8. SYSLI8, COLLIB, and 
CY8IIL8 from the INTKDEV1) catalog and by 
loading selected files from the DUNPPF tape 
mounted on the unit specified by the W SC W 
parameter. This parameter lu&l be 
specified for the INT2(DEV2) catalog to be 
updated* 

b. L0ADPF»s the latest system Into the 
INTKDEV1) catalog from the DUMPPF tape 
mounted on the unit specified by the "WC W 
parameter {defaults to M 50*M. 

c. SYSEDIT's the A170 Remote Host and 
Interactive binaries if the "SYSEDIT" 
keyword is specified. 

d. LGADPF's the Confidence Test binaries from 
the file CONFTST. and then purges CONFTST 
from the catalog* 

3) Bring up A170 Remote Host and Interactive* 

TAFNVE. 

4) Bring up dual state* 

Hake sure the NVE Subsystem Environment Is set up* 

X.S£TVE(D£V1#UM»0EV1.C»6) Then bring up the NVE 

Subsystem* n.NVEDEVl. (where n is any free NOS 
control point) 

5) When the NVE control point requests the Operator 



4-6 
ADVANCED SYSTEMS INTEGRATION PROCEDURES NOTEBOOK - Cycle 3 

05/22/82 

4.0 NOS/VE HARDWARE REGRESSION TESTING 

Facility control point* do? 

K#n» (where n is the OPFAC control point) 

6) Bring up NAHJ 

FNC5*7700. 

N.NAHS2. (where N /* 2 i s NAM control point) 

7) Build and save the 18C object files needed to complete 
deadstart of NOs/Vt (and needed to perform subsequent 
deadstarts of this system)* znd begin execution of the 
180 system tasks to support Interactive* Remote Host* 
and the dayfile displays: 

K.LIU (D£V1*NVE) DEV1X. 

K.GETF DS 

K.DS TRUE FALSE FALSE TRUE SIF«TRU£. 

8) tfhen the system displays the message "READY FOR 
COMMANDS"* start loading the Confidence Test Base into 
the system (see Section 4.6 below). Make sure that the 
ASCII printer is ready* i.e. that the START light is 
lit and that a "F0RM33* TM.» has been entered. To 
monitor the 180 jobs as they enter the system*do K.VED 
CP to bring up the NOS/VE control point display. 

9) The system is now ready to be taken down! 

N.CF0.DI*NE. (N is the NAM control point; this 

dlsabl es NAM) 

2.ST0P* (Bring down 170 Interactive* Remote Host* 

and Operator Facility) 

K.*8YEV£. (Bring down NOS/VE) 
IMPORTANT* This last step must be performed at the NVE 

Subsystem K display* NOT the Operator Facility K 

display* 
When all control points are "quiet*** proceed to the next 
step. 

10) Bring down A170 N0S« 

AB. 

CHECKPOINT SYSTEM. 

E*M. (make sure that all checkpoints complete) 

STEP. 



4.4 imDau£naii-iQ.ca!iEia£uc£-i£sis 

The confidence test base is a set of tests*used to 
determine if a build is ready* for installation in an closed 
shop environment. The test base consists of a set of tests in 
each area of the operating system* presently under analysis by 
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the evaluation unit. The tests are described in section 4.7* 
Any questions or problems should be addressed to R. E* 
Jarosz» x6834. 



4.5 IMSIALUUflM 

The following procedure should be followed when installing 
this test base* 

1* REQUESTS A PE»V$N«CNF TAP, NT, D»»E*LB«KL*F»I*P0«R. 
2. L0ADPF,8«TAPE»TY=ALL 

This Mill install two files. 
1. The test source PL (CONFPL) 
2* The SES procedure library (CNFpRQC) 
3 Load any files frcm a tape created with the CLEANUP 

procedure* 
4. Two variables must then be added or changed in the user 
PROFILE, 

They are as fol lows • 
\ USE8IN * «0LC» 
\ RUNLVL - *DEV1» 

For more information on these profile variables refer to 
sections 4.8*2 and 4*8.4. 

At this point the confidence test base is installed and 
ready to be run* 



4.6 £*£CUIIfJM 

Before the tests are executed it is necessary to establish 
the ACR routines which collect the test results* Because of 
the changes* that are on going in ACR* the routines will 
remain under the control of the Evaluation Unit. To use ACR* 
do the following before executing any tests. 

1. GET, ACRJ08/UN-EVAL. 
2* ROUTE. ACRJ08.DC«IN. 

You are now ready to execute the tests in the confidence test 
base* To begin do the following! 

SE$*LPFN«CNFPR0C.L0TB DM 3 AQ01 . .RH021 ) B»C0NFPL OLD.* . 
..? DELAY-20 

At this point* you can run test IF094 by following the 
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instructions in section 4.6.1 of this document. 

After ail the tests haye completed* do the fol lowing 
replacement of ACR results files to the 170* 

G€Ttj081/UN«DEVl 
R0UT£,J0B1#DC«1N 

At this point* run the RESLTS procedure to recieve the ACR 
results listing. 

This job will also produce a 180 listing* of the system 
statistics* for comparasion purposes, 

SEStUN.EVAL. RESLTS I-RESULTS 0* I i st ing_f I I e 



4.6.1 EXECUTION OF IF094 

This test Is somewhat different in that it requires running 
by hand under NOS/VE IAF. To execute this test do the 
fol I owing. 

On NOS 

S£S*LPFN«CNFPROC.GENBIN Q»IF094,B«XI FQ94* . . 

PL»C0NFPL*CI#S»180»0LD 
This will create the object code part of the test. 
ON NOS/VE do the following* 

ATTACH_FILE .EVAL.E VAL.SETUP 

INCLUDE_FUE EVAU.SETUP 

ACR TEST.NAHE-IFC94 PRODUCT_IDENTI FI ER«IF 

GET.FILE TO-XIF094 DATA_C0NVERSiaN*B60 

EXECUTE_TASK P ARAMETERS«»XIF094#LG0« ,SP«CIT0II >LI BRARY»SYSL 

LGO 
At this point do whet the program tells you to. 
If you feel it performed as expected do the following! 

ACR STATE«PC REP0RT»TRUE ACTI0N«FULL 
Otherwise 

ACR STATE-FAIL REPQRT-TRUE ACTION-FULL 



4.7 mis 



TEST TEST FUNCTIONS 

****** ************** 

BAC01 AMPSFILE 
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8A024 
8A027 

8A048 



3A055 
8A0&2 
CH001 



CL029 
CL039 
CL058 
CL061 
CL103 
L0034 
LD037 
0C044 
PF101 
PF125 
PF140 
PF145 
PF156 
PF157 
PM016 
PMQ50 
QF100 
RH001 
RH011 
RH014 
RH021 
IF094 



AMPSGET.FI 

AMPSGET.DI 

AMPSPUT.DI 

AMP$GET_N£ 

AMP$PUT_NE 

AMP$GET_PA 

AMPSPUT.PA 

AHPSGET.SE 

AMP$GET_SE 

AMPSGET.SE 

AMP$GST_FI 

COPY 

PHP$ESTA8L 

PMPSDISEST 

PMPSCONTIN 

DISPLAY J/A 

DECLARE_VA 

EXIT* CYCL 

IF CLAUSE 

FILE CONNE 

BASIC LOAD 

PMPSEXECUT 

RETAIN IN 

VERIFY FIL 

VERIFY LFN 

VERIFY FIL 

CHANGE 

DEFINE_CAT 

PURGE_CATA 

OSPSAWAIT. 

JOB LOCAL 

SUBMIT 

GET 860 

REPLACE A6 

REPLACE A8 

GET 856 

VERIFY CON 

INTERACTIV 

TERMINAL A 



LE. ATTRIBUTES 
RECT 

RECT 

XT 

XT 

RTIAL 

RTIAL 

GMSNT_P 

GMENT_P 

GMENT_E 

LE.ATTR 



OINTER 
OSITION 
01 
I3UTES 



ISH_CQN 
A3LISH_ 
UE_TO_C 

LUE 
RIA3LS 



DITION_HANDLER 

COND_HANDL£R 

AUSE 



CTIONS 

€R OPERATIONS 

E 

CREATE^ 
E CYCLE 
>PFN R£ 
E CYCLE 



OBJECT LIBRARY 
S (DEFINE) 
LATIONSHIP 
S <PURGE) 



ALOG 

LOG 

ACTIVITY COMPLETION 

QUEUES 



DITIONA 
E INPUT 
TTRISUT 



L.BREAKS 
/OUTPUTS 

ES 



NOTEl IFQ94 MUST BE EXECUTED BY HAND. SEE Section 4,6.1. 



*.8 IflflLS 

This section describes the ACR and SES procedures* used by 
the tests* in the confidence test base. 
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4.8,1 AUTOMATIC CHECKING ROUTINES - ACR 

The 180 common ACR is described in the Interim Test Tools 
ERS, (DCS number ARH4207) 



4.8.2 LDTB 

This SSS procedure Is used to load a set of tests into the 
170 input queue* from a Hadify source program library. The 
parameters are shown below* 

DECK \ D* This required parameters is a list of deck names 
that are to be expanded and loaded. This parameter may be 
a list* a range or both. Because these decks are expanded 
by HADIFY they can not be common decks, 

PL J 9« This required parameter is the library where the 
decks listed on the preceding parameter reside. 

DELAY* This parameter specifies the number of seconds 
between submission of jobs. If it is ommitted* 60 is 
assumed. 

JN* This parameter is the user number where the program 
library specified on the PL parameter resides. If It is 
ommitted* the user number of the executing job is 
utilized. 

OLD J NEW« This keyword is used to replace the Profile 
variable USE8IN. This profile variable is used by the 
GENBIN procedure (see Section 4.8.4), This parameter allows 
for a decision* to be made at execution time* on whether or 
not to create any binary files needed with this test. 
The default is NEW. 

PRINT I NQPRINT* This keyword determines if the 170 output 
file is printed or not. The default is NOPRINT. 



4.8.3 CLEANUP 



When tests use the GENBIN procedure* to create 
code* two files are created (DUHPDIR and PURGEF). 
procedure uses these files to archieve the object 
and purge them. The parameters for CLEANUP are 



CI object 
The CLEANUP 
code files 
shown below. 
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VSN* This required parameter Is the v*SN of the tape* where 
the DUMPPF Is done* 

KL ? KIM This optional keyword describes the label 
characteristics of the tape specified above. The default 
Is KL. 

NOTE* The following table shows the other characteristics of 
the taoe specified on the VSN parameter. 

TRACK NT (nine track) 

DENSITY PS (1600 bpi) 

FORMAT I (internal) 

The file written on this tape can be reloaded using the LOADPF 
UTILITY. 



4.8.4 GEN3IN 



This procedure optionally creates a CC or CI object file 
fro* an expanded cybil source file or MADIFY deck. The 
Parameters are shown below. 



D ; J J ALL* This is the list of HADIFY decck names to be 
expanded and compiled. 

PL* This parameter is the library where the decks specified 
on the previous parameter reside. 

AB J APL* This optional parameter describes the 

user numbered file names* to be considered as alternate base 

for expansion of decks or source files. 

JNt This optional parameter is the user number of the file 
specified on the PL parameter. 

SFt This parameter Is an optional file name* telling the 
procedure to work from a source file instead of a MADIFY 
deck. 

CF: This Is the file name where the expanded deck will 
reside, and it is the input file to CYBIL. 
The default is COMPILE. 

L : This Is the file where the CYBIL compilation listing 
Is placed. The default is LISTING. 
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SYS * Si This parameter causes a specf ic file to be used as 
a alternate base as shown by the following table. 



SYS 


FILE 


! 101 ! 


CYBICMN/UN=S£S S 


J 170 ! 


CY8CCHN/UN-SES 1 


S 180 


} OSLPI/UN»lvl 



LVLi This optional parameter is the 
Mill be used as an alternate base* 
the profile variable RUNLVL or DEVI 

BIN J Bt This required parameter is 
checked for when the keyword OLD is 
also the name of the file where the 
reside if NEW is specified. 



I oc at ion of 
The default 



the name of 
speci f i ed* 
object code 



OSLPI that 
is ei ther 



the file 
It is 
wi I I 



CC * CI* This parameter is unique In that the value is 
used along with the keyword* If Just the keyword is coded 
the proper compiler is recieved from a default user number* 
If the value is coded the proper compiler is received from 
the used specified* The default user number is either the 
value of the RUNLVL profile variable or DEVI* The default 
value for the keyword is CC. 



NEW S OLD* This keyword determines if the object code file 
coded for the 8 parameter will be produced or net. If NEW 
is coded the file coded on the 3 parameter will be created. 
If OLD is coded and the file exists then that file will be 
used and no compilation takes place. If the file does not 
exist then the file will be created. 

The default value used is taken from the USE8IN profile 
var I abl e* 
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4.8. 5 RRTUST 



This procedure is totally internal to the tests and the 
discussion is left to the help file. 



Al 
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Originator .. DATE I _£ Transmittal No. 

A* Code Location! (£A££ed Modsets) FN* _. UN« 

(Decks in "QgQUl" format) FN»_. UN« ... 

Code Description File* FN* _, UN» __ * 

IF module has a call bracket of D OR 

code affects system user in some other nay THEN 



Corrective Code t 3 



Usage Changes Desc. File! FN* UN' 

Code Destination (if a&t NOSVEPL): PL* „, 

BJ Modset Identif ier(s) _. .. 

New Feature £ 3 OR 

Module(s) to be recompiled _, _, 

How has this code been tested? (Use right margin*) 

NOTE* If any of these are checked* then explain in right margin. 

Installation procedure changes required? t ..3 

Dependent upon other feature* fix* or tool? £_ 3 (List below) 

OSLPI or Internal Interface changes requi red? t _1 

Should GNVEMT (Generate N0S/V5 Message Templates) be run? £_ 3 

More forms are on FN * XMIT10 UN * 0EV1. 

* Attach copy of description file to form (both 14 7/8 by 11). 
Format is t #NODSET_IDENTIFIER (or NSy_D£CK_NAM£ ) (upper case) 
£PSR Number (Omit if feature code*) 
Descriptive text which describes code content 
**DECK_MODIFI£D (or NEW.DECK.NAME ) (upper case) 

** Attach copy of Usage Changes Description File to form 
(both 14 7/8 by 11). 



** 



Description File £___. 

Proof of Compi I ationC 

Proof of Execution £_„. 

(Usage Changes Desc*C 

(PSR) C 



aEEEHQEacx-kisi 



(Continue in right margin) 



Tar get 8ui I d 

Should this code be added to the successor build cycle? C 3 
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I USER * J * 

1 NUMBERS J FILENAME(S) 3 FUNCTION J VERSION/FREQUENCY Of UPDATE 


J 3 3 3 

5 INTl/lNTH J NQSVEPL 3 MADIFY program library J Matches the level of system 
3 0EV1/DEV2 3 3 of Virtual State code 3 binaries contained In same 
3 3 J 5 catalog. Updated on periodic 
3 3 3 * scheduled basis* 


3 INT1/INT2 3 OSLPI 3 MADIFY program library \ Matches the level of system 
1 DEV1/DEV2 3 3 of NOS/VE Program 3 binaries contained in same 
• * * Interface decks* J catalog* Updated once for 
S S ' 3 each bu I Id eye 1 e* 


S INT1/INT2 J VE170PL 3 MADIFY program library t Matches the level of system 
3 DEV1/0EV2 S * of NOS code which 3 binaries contained in same 
5 3 J supports NOS/VE* 5 catalog* Updated on 
3 3 3 3 periodic scheduled basis. 

J 3 J MODIFY Program library ! Updated on a scheduled basis. 
3 LIBRARY 5 OPL J which matches NQS 3 (CPUMTR which supports NOS/VE 
3 3 3 system level for 32. J is on VE170PL and aat 
J 3 J (Installed on FMD 3 on this PL). 
3 3 3 unit V3). J 

3 INT1/INT2 3 SESPLI8 3 Command Language 3 Matches the level of system 

% DEV1/DEV2 3 3 Procedure Library J binaries contained in the same 

3 3 3 (Documented in 3 catalog* and accesses the 

J J J Integration Proced- ! appropriate build tool 

3 3 J ures Notebook)* J versions* Scheduled updates* 

3 magnetic 3 listing files J Contains compilation/ J Matches the level of system 
3 tape 3 3 assembly listings of J binaries contained in the 
3 3 3 all Virtual State 1 same catalog* 
3 3 3 code* Accessed via 3 
J 3 3 LISTNVE procedure. J 


3 INT1MNT2 3 MTRXLCB* J Linker directives files 3 Matches the level of 

3 DEV1/DEV2 3 E ILCB*SYSXLC B 3 for monitor* 3 system binaries contained 

3 J JOBXLCB •BBBXLC8 3 error Interface* J in the same catalog. 

3 3 J system core* job J EI is built using the 

3 3 J template* and user J BlDEI procedure* 

3 3 3 modules respectively* J 


3 INTI 3 NEWDKPL J Meaningless Madify J Never* disappears when SCU 
3 DEVI 3 3 Program library J conversion is complete* 
3 3 3 which users may 3 

1 J 3 substitute for 3 
3 J J as an alternate 3 
3 3 3 base when using J 

2 3 3 Integration compilation 3 
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1 ? * procedures* J 


: : : ; 

S INT1/INT2 J PMPXX I Contains link map of J Each Velink of a 
S DEV1/0EV2 ! PMPXXYY I particular system \ Production/Recovery 

• S RMPXX * created* where RMPXX J System Core/Job Temolate. 
J ! J RMPXX are the Production/; 

• J ? Recovery System Core J 
J J J Maos and P^IPXXYY/RMPXXYY J 

t * ' are the Production/Recovery 
1 S * Job Template maps* « 

J INT1/INT2 S PSYXLOR J Contains VS generator J As required by system 
J 0EV1/0FV2 J RSYXLOR J directives for Dual J content or structure 
I \ J State offset loads* J changes. 


J INT1/INT2 ! KFYDESC J Contains Keypoint i Non-standard* updated 

J D&V1/DEV2 * * descriptions for J upon development's request. 

5 1 S the Keypoint report J 

! 1 \ Program XXM7KSY. 


I INT1/INT2 ! PMTXDBG>RMTXDBG J Contains debug tables \ Each Velink of a Production/ 
J DEV1/DEV2 J PSYXD8C*RSYXDBG J produced by the linking J Recovery System Core/Job 
J 5 PjBXDBGf RJBxDBG J of the system* J Template. 



— + 
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INT1/ 
DEV1/DEV2 



XLMMTR 



Obj 
of 
exe 
mod 



ect te 
modu I e 
cute i 
e • 



xt file 

s which 
n monitor 



Each recompi I at ion of a 
monitor mode module* 



INT1/ 
DEVI/ 



INT2 ! 

DEV2 ? 

t 

* 



XLS113, 

XLS133*XLS13D* 

XLS100 



Ob J 

of 
mod 
job 
in 



ect t e 
system 
u I es *# 

mode 
ring 1 



xt files 

core 
hi ch run in 
and execute 



Each recompi I at i on of 

a system core 

module within these libraries* 



.-.+ 



INT1/INT2 
DEV1/0EV2 



XU223* XLJ236, 
XU266*XU23D* 
XLJ2DD 



Obj 

of 

mod 



ect te 
job te 
u I e s • 



xt flies 

mpl ate 



Each recompi I at Ion of 

a job template 

module within these libraries* 



INT1/ 
DEVI/ 



INT2 J 
DEV2 J 



XUOSUXLJLIB* 

XLJB88*XU0CM 

XUSG 



Object text f i les 
of Remote Host* 
Interactive* CITOII* 
the Object Library 
Generator* and various 
user utility programs* 



Each reccmp I I at ion of a 
module within these libraries* 



INT1/INT2 
DEV1/DEV2 



PHTSTXX. 
PSYSTXX* 
RNTSTXX 
RSYSTXX 



Outboard symbol 
tabl e f i I es for 
Production/Recovery system 
Monitor* and Production/ 
Recovery System Core 
produced by 
VELINK* 



Each Vel ink of the 
system* 



4.™ — .—-. 
I INT1/INT2 
DEV1/DEV2 



PSYXX*PJBXXYY 
RSYXX*RJBXXYY 



The 
onm 
due 



Virtu 
ent fi 

ed by 



a I Envir- 
Iss pro- 
V6GEN. 



Each VELINK/VEGEN 
of the system* 



— + 



INT1 
DEVI 



NOSTEXT*PSSTEXT 
SSYTEXT 



A17 
tex 

NOS 



NOS 
ts for 
versi 



system 
current 
on* 



Each A17C NOS update. 



INT1/INT2 
0EV1/0EV2 



XXH7KEY 



program to report 
NOS/VE Keypoints 
encountered during 
a s I mul at ion run* 



Non-standard ISWL 
uti I ity* 



INT1/INT2 J XXM7DSI 



NOS/VE deadstart 
f i I e generator* 



Non-standard* supplied 
by the Deadstart project* 



INT1/INT2 
0EV1/0EV2 



XIDST*XMOD* 

XIDSP*XIHLP* 

XIR£S*XSMA* 



CYBER 180 PPU 
programs* 



Upon demand* 
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S J XD5B,XD5CjXD5C2> J J 1 

S ! XHSPHCU J ! I 

+, +.__. . + , — 4.- — - • . + 

J INT1/INT2 J TPXXXK ! Dual State J Each tiine a new \ 

\ 9EV1/DEV2 J J deadstart file 1 deadstart file is \ 

X \ \ created by the NVESYS 5 generated (upon 1 

» J » procedure. ' demand). ! 
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C1.0 BUILD CATALOG SETUP 



C1.0 aUIU-£lIliJ3ia-S£iy£ 



Before beginning the CY3IL compiler builds* perform the 
following setup process in the build catalog: 

1) S£T,PRQCFIL/UN«LP3. 
SAVE,PROCFIL/CT*S,N*R. 

2) DEFINE*CYBPLIB/CT*StH*R, 
ATTACH, $ESPLIB/uN*LP3. 
C0PY,SESPLI8,CY8PLIB,V. 
RETURN,SESPLIB,CYBPLI8. 

3) Check that the PROFILE variable "PASSWOR" is defined, 
and set to the password of the build catalog* 

4) Check that the Deferred Batch job limit is set to 
UNLIMITED in the build catalog. 

All CYBIL build procedures are on the INTl SESPLIB* They 
Hill generally be run, however, in a catalog atbfic tiiaa an 
official Integration catalog. Therefore, all procedures 
outlined below should be called via » , SES,INTl.<Procedur e 
Name>", or else add INTl to the PROFILE variable SEARCH list 
in the bui I d catal og« 

The general CYBIL build atafiS-SS is documented in the next 
section* The individual atflfiSiJilX^S are documented in 

subsequent sections* 
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C2.0 CYBIL BUILD PROCESS 



C2.0 £iaiL-auii.a.aaac£i5 



The various CY8IL compilers are built and tested in the 
following order* via the procedures indicated* 

BLDCC 1) 8uiJd the CC compiler front end and code 

generator; link them together to form the 

CY8ILC compiler; build CYBCLI8. 
TESTCC 2) Test the execution of the CC compiler and 

CYBCLI8. 
CNVRGCC 3) Test the CC compiler for convergence (i.e. 

can it compile itself and produce identical 

binaries); rerun tests from 2) above, 
BLDCI 4) Build the CI code generator with the CYBILC 

compiler built in l)-3) above; link it with 

the common front end built In 1) above to form 

the CYBILI compi I er • 
TESTCI 5) Test the execution of the CYBILI compiler. 
BLDILI3 6) Build CYBILI3 with the CYBILI compiler built 

In 4) above? test the new CYBILI8 with 

CYBILI. 
RUNREG 7) Set up the environment for running the CI 

compiler regression tests and submit them. 
BLDIIS 8) Build and test the II compiler for the 

si mutator • 
3LDII2S 9) Build and test the II 0PT*2 compiler for the 

slmu I at or. 
8LDIIH 10) Build the II compiler for the hardware. 
RUNREG 11) Set up the environment for running the CI 

compiler regression tests with the M 0PT*2 W 

option specified on the compiler call* and run 

them. 

l)-6) liiSi be run serially; 7)-10) may be run 
concurrently. 11) cannot be run until 7) has completed. 
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Each CYBIL build procedure that resides on the Integration 
SESPLI8 Is outlined below. Note that most procedures have a 
"CHAIN* parameter. If "CHAIN" Is keyed on any one of the 
procedures* all subsequent procedures will be automatically 
submitted at the appropriate times in the order specified 
above. This allows you to submit all build jobs by typing in 
only one procedure call ("SES. BLDCC CHAIN'*)? it also allows 
you to restart the build Process at any point should errors be 
di scover ed. 

Note also that the CC and CI procedures write status 
messages to the indirect access file CY8STS in the build 
catalog. This file can be interrogated on-line or printed to 
obtain the results of the building and testing stages of these 
compilers. The II compiler builds produce listings which must 
be checked to verify that the compilers were indeed correctly 
built (see procedure descriptions below). 



C3.1 ££_£QH£IL£&_ama-ABD-IISI-££Q£I&UR£S 



C3.1.1 BIDCC PROCEDURE DESCRIPTION 

The SES procedure BLDCC builds the CYBIL CC front end and 
code generator binary libraries (PFELIB and PCGLIB7* 
respectively) and then links them together to generate the 
CYBILC compiler. At the same time* it recompiles the changed 
CYBCLIB modules* saves them on an object file (CY8CQ3J)* and 
REPULIB's them onto the existing SES version of CYBCLIB to 
generate the Ufidltfill CYBCLIB, Status messages are written to 
the file CY8STS in the current catalog (BLDCC is the sal* 
procedure which purges this file if it exists; all other 
procedure append Information to the end of the file). 

BLDCC creates the following permanent files in the build 
catalog* PFELIB* PCGLIB7* CY8C0BJ* CYBCLIB* CYBILC* CMAP* 
CY3STS. The format of the BLDCC Is as follows: 

SES. BLDCC £ m « < (list of) module name(s) > 3 
C fe 1 cc 1 
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C chain 3 
I local! 

m i The name(s) of the CC compiler modules to 
compile* The default is to compile all CC 
compiler modules. 

fe J cc i Keyword indicating whether the modules specified 
by H H M are front end (fa) or code generator (cc) 
modules. This keyword Is ££aui££4 if "H M is 
spec i f i ed • 

chain * Option to submit subsequent CY8IL build jobs 
after 8LDCC completes. The default is to qq.£ 
submit these jobs. 

local t Run 8LDCC In LOCAL mode. The default is to run 
it in BATCH. 

C3.1.2 CNVRGCC PROCEDURE DESCRIPTION 

The SES procedure CNVRGCC tests the CC compiler built by 
the 8LDCC procedure for convergence. This means that the 
compiler must be able to compile itself. producing binaries 
identical to those which make it up. First it saves all the 
files created by 8LDCC by copying them to files named by 
changing the first character of the f i le name to W A M (e.g. 
PFELI8 -> AFELIB. CYBCLIB -> AY3CLI8, etc.). It then rebuilds 
the front end* code generator* and CY8CLI8 binaries with the 
CYBILC compiler built by the BLQCC procedure* generates and 
tests a new compiler* and compares the new binaries to the 
previously built ( w A w -pref I xed) ones. If the binaries are n.c.1 
identical* CNVRGCC makes a second attempt at convergence (this 
time saving the binaries on ^"-prefixed files) and again 
compares the binary libraries. If the binaries verify, the 
job to build the CI compiler (BLOCI) is submitted? if they do 
Dfljfc verify after 2 attempts at convergence* the procedure ends 
and the CYBIL project must be notified. Status messages are 
written to the indirect access file CYBSTS in the current 
cata I og. 

CNVRGCC creates the following permanent files in the build 
catalog! AFELIB* ACGLIB7, AY9C03J* ACYBlLC* AYBCLIB, ACMAP 
(also 8FELIB* BCGLI87* BY8C0BJ. 8CY3ILC, BYBCLIB, BCHAP if 
convergence does not occur on the first iteration). The 
format of the CNVRGCC is as follows* 
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C3.1.2 CNVRGCC PROCEDURE DESCRIPTION 
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SES. CNVRGCC t chain 3 
C ioca I 3 

chain s Option to submit subsequent CYBIL build jobs 

after CNVRGCC completes. The default is to qq£ 
submit these jobs. 

local t Run CNVRGCC in LOCAL mode. The default is to 

run it in BATCH. 

C3.1.3 TESTCC PROCEDURE DESCRIPTION 

The SES procedure TESTCC runs the CYBIL compiler tests 
SEOUEN* EXITLP# and PPR0C2 against the CYBILC compilers built 
by the 8LDCC and CNVRGCC procedures* These tests reside on 
the test base TESTPL in the HAW catalog. Status messages are 
written to the indirect access f i le CY8STS in the current 
cata I 09. 

TESTCC creates no new permanent files. The format of the 
TESTCC is as follows* 

SES.TESTCC C cnvg 3 
C chain 1 
t local 3 

cnvg J Keyword indicating that the compiler being 

tested was built using the CNVRGCC procedure. 
This parameter is needed to make the status 
messages written to CY3STS more meaningful. The 
default assumes that the CYBILC being tested was 
built by BLDCC - i.e. It has not gene through 
convergence yet* 

chain * Option to submit subsequent CYBIL build jobs 

after TESTCC completes. The default is to aai 
submit these jobs. 

local t Run TESTCC in LOCAL mode. The default is to run 

it in BATCH. 

C 3 . 2 tt-COHEUER-fimD-AMfi-IESI-£&aCEQi&£S 
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C3.2.1 8LDCI PROCEDURE DESCRIPTION 

The SES procedure 3LDCI builds the code generator binary 
library (PCGLI88) for the CY8IL CI compiler. It then links 
this file with the common front end (PFELIB) produced by the 
BLDCC procedure to generate the CY3ILI compiler* Status 
messages are written to the indirect access file CY8STS in the 
current catalog* 

BLDCI creates the following permanent files in the build 
catalog! PCGLIB8* CYBILI. CMAP8. The format of the BiDCl is 
as follows* 

SES. BLDCI C m * < (list of) module name(s) > 3 
C chain 3 
C local 3 

m i The nameCs) of the CI code generator module(s) 

to be compiled. The default Is to compile ail 
CI code generator modules. 

chain t option to submit subsequent CY8IL build jobs 
after BLDCI completes. The default is to Bfii 
submit these jobs. 

local * Run BLDCI in LOCAL mode. The default is to run 
It in BATCH. 



C3.2.2 TESTCI PROCEDURE DESCRIPTION 

The SES procedure TESTCI runs the CYBIL compiler tests 
SEQJENt EXITLP* and PPRQC2 against the CYBILI compiler and 
CY8ILIB (built by BLDCI and 8L0ILIB, respectively). These 
tests reside on the test base TESTPL in the HAW catalog. 
Status messages are written to the indirect access file CYBSTS 
in the current catalog. 

TESTCI creates no new permanent files. The format of the 
TESTCI is as follows* 

SES. TESTCI C lib 3 

C chain 3 
C local 3 

lib * Keyword indicating that this run of TESTCI tests 
the CYBILIB built by 8LDILIB. This keyword is 
needed to make the status messages written to 
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CY8STS more meaningful. The default assumes 
that this run of TESTCI tests the CYBILI 
compiler built by 3LDCI. 

chain s Option to submit subsequent CYBIL build jobs 
after TESTCI completes. The default is to Qfli 
submit these jobs. 

local J Run TESTCI in LOCAL mode. The default is to run 
it in BATCH. 

C3.2.3 BLDILI8 PROCEDURE DESCRIPTION 

The SES procedure BLDILI8 compiles the CYBILIB modules 
which have changed and saves them on the object file CYBIOBJ. 
It then G0L f s them on the current SE$ version of CYBILIB to 
generate the updated CY8ILI8. BLDILIB also creates the 
CYBILGO file which is used in creating the version of CYBILIB 
which is used on the hardware (done in OS). Finally* it 
resubmits the CI compiler tests {TESTCI with W LI8 M option 
specified) which now use the qsw. CYBILI3 as a means of testing 
CYBILIB. Status messages are written to the indirect access 
file CY3STS In the current catalog. 

BLDILIB creates the following permanent files in the build 
catalog! CYBIOBJ, CYBILIB* CYBILGO* L8SRC80. The format of 
the BLDILIB Is as follows* 

SES. BLDILIB C chain 1 
t local ] 

chain f Option to submit subsequent CYBIL build jobs 
after BLDILIB completes. The default is to nsi 
submit more Jobs* 

local i Run BLDILIB in LOCAL mode. The default is to 
run it in BATCH. 



C3.2.4 RUNREG PROCEDURE DESCRIPTION 

The SES procedure RUNREG sets up the build catalog 
environment to be able to run the CI compiler regression 
tests* The tests reside on an SCU test base PL In the HAW 
catalog. RUNREG first creates the alternate SCU base "MYBASE" 
in the build catalog which allows for the regression tests to 
be run from that catalog* It then submits the deferred batch 
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C3*2*4 RUNREG PROCEDURE DESCRIPTION 



job which runs the tests (CY0G1 . .CY999 ). To obtain the test 
results* run 

$£S#LPFN»CY8PLIB*RUNANL 

the morning after the regression tests are run* In order to 
run this procedure* the deferred batch limit in the build 
catalog IJJSl be set to UNLIMITED* and the user must have the 
PROFILE variable "PASSWOR" defined* 

RUNREG creates the following permanent files in the build 
catalog* MYBASE* CIDAY. The format of the RUNREG is as 
fol I ows* 

SES.RUNREG C op t2 3 
I local 3 

opt2 t Option to test the compiler with the 0PT«2 

option* The default is to run the tests aitufliil 
the 0PT«2 option* 

local t Run RUNREG in LOCAL mode* The default is to run 

it in BATCH* 



C 3 • 3 II.£Q!l£lL££S.auiLtt-Alitt-I£SI-EaQ*;£ DU££S 



C3.3»l 8LDIIS PROCEDURE DESCRIPTION 

The SES procedure BLD2IS builds the front end and code 
generator binary files (CYBIIFE and CY8IICG* respectively) for 
the II compiler for the simulator, and then links these two 
files together to produce the compiler checkpoint file (IICPF) 
used as input to the simulator. It then submits a simulator 
test run of this compiler* The output of this test run 
consists of a compilation listing (which should contain jjo, 
compilation errors)* the simulator SESLOG* and a dayfile 
(which should also show no compilation errors)* 

BLDIIS creates the following permanent files in the build 
catalog! CYBIIFE, CYBIICG* IICPF* IIMAP. SESLOG* LISTX. The 
format of the BLDIIS is as follows: 

SES.BLDIIS C local 3 

local « Run BLDIIS in LOCAL mode* The default is to run 



C3-7 
CY8IL Installation Documentation 

05/22/82 
Object Text F I les 

m mm mm mm mmmmmm mm mm mm mm mm mm mm mm mm mm m m m m mmm m mm mm mm mm mm mm mm mm mm mm mm m m mm i 

C3.o cybil BUILD PROCEDURES 
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it in BATCH, 

C3.3.2 BLDII2S PROCEDURE DESCRIPTION 

The SES procedure BLDIX2S builds the front end and code 
generator binary flies for the II 0PT»2 compiler for the 
simulator ICYBI2FE and CYBX2CG* respectively), and then links 
these two files together to produce the compiler checkpoint 
file (I2CPF) used as input to the simulator. It then submits 
a simulator test run of this compiler* The output of this 
test run consists of a compilation listing (which should 
contain fla compilation errors)* the simulator SES LOG* and a 
dayfile (which should also show no compilation errors). 

BLDII2S creates the following permanent files in the build 
catalog* CYBI2FE* CYBI2CG* I2CPF, I2HAP, SeSLOGj LI5TX. The 
format of the BLDII2S is as follows* 

SES.BLDII2S C local 3 

local * Run BLDII2S in LOCAL mode. The default is to 

run it in BATCH. 

C3.3.3 8LDIIH PROCEDURE DESCRIPTION 

The SES procedure BLOIIH builds the front end and code 
generator binary files (CYBHIFE and CYBHICG* respectively) for 
the II compiler binary that is used on the hardware. At the 
same timet it generates the II hardware version of CYBILIB 
ICYBHQBJ). It then takes these three files and some other 
miscellaneous routines and GOF's them together to create the 
UttCQ&XE&IEl} «"<* UtUUUiUQ version of CY3IL II (CYBHBIN). 

BLDIIH creates the following permanent files in the build 
catalog* CYBHIFE* CYBHICG* CYBHQ3J* CYBHBIN. The format of 
the BLDIIH Is as follows* 

SES .BLDIIH t local 1 

local * Run BLDIIH in LOCAL mode. The default is to run 

it in BATCH. 
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01.0 KEYPOINTS 



D1.0 ££I£QIMIS 



Keypoints are used to give an execution time trace of 
program flow by showing that a given function is being performed 
{that is* that a given procedure is being executed) . 
Keypoints may also be used to display request parameters* 
status and error conditions* 



01.1 IimiiS J££XEflim-ERaH-£X&IL-£QI2£ 

The general form of the keypoint instruction is* 
♦ INLINE (tkeypointS kevpo in t.c I ass* oskSm * data* keypo in t_i d ) ; 

01*1.1 KEYPOINT CLASSES 



A keypolnt is identified by both class* and identifier. 
The following deck explains the partitioning of the keypoint 
classes* 

0SDKEYS 
COMMON 

CONST 

€ Keypoint Classes * 
< 

€ The 16 keypoint classes supported by the hardware are 

£ partitioned between the System* Product Set and User as follows, 

osk$systeit!_cl ass « C . . 5 >* 
osk$pr oduct_set_cl ass * 6 C 6 •• 10 >* 
osk$user_class « 11 C 11 #. 14 >* 
osk$pmf.contro I • 151 
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Dl.O KEYPOINTS 

Dl.1.1 KEYPOINT CLASSES 



£ Keypoint Multiplier: 

£ 

£ By convention* 

£ the 32 bit keypoint code supported by the hardware 

C is split into two fields* The right field contains a keypoint 

£ Identifier which is used to identify a function within a 

£ keypoint class* For example* if a particular keypoint class 

£ represents exit from a procedure* 

£ then the keypoint identifier Might identify exit from 

£ procedure A versus exit from procedure 8* 

£ The left field is used as a data parameter appropriate to the 

£ function identified by the keypoint identifier* In the 

£ procedure exit example above* 

£ the data parameter field might be used to indicate the 

£ status of the procedure call, 

£ The keypoint multiplier is used to partition the keypoint 

£ code into the two fields* The data parameter should be 

£ multiplied by the keypoint multiplier to prevent it from 

£ overlapping the keypoint identifier field. 

CONST 

oskSn * 40961 



01.1.2 NOS/VE KEYPOINT CLASSES 

Five keypoint classes named ENTRY* EXIT* UNUSUAL, DEBUG* 
and DATA are defined* taking five of the available sixteen classes 
by the hardware. 

ENTRY ■- Every gated procedure plus all major internal procedures 
(those shared across functional areas) should contain a 
keypoint of this class* These keypoints should be placed 
as close as possible to the entry to the procedure. 

EXIT - Every gated procedure plus all major internal procedures 
(those shared accross functional areas) should contain a 
keypoint of this class* These keypoints should be placed 
as closed as possible to the exit to the procedure. 

UNUSUAL - Every situation which is unexpected or quite unusual 
should contain a keypoint of this class. It is intended 
that these keypoints would be enabled at ail times. The 
frequency of encountering these keypoints SHOULD BE 
very low. The DATA keypoint class is not allowed in 
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conjunction with a keypoint of class unusual. 

DEBUG - These keypoints are for providing additional trace 

information as an assist in debugging hardware or software 
Problems. DE8U6 class keypoints would be most useful in 
the more complex areas of the system. 

DATA - This keypoint class can be used with ENTRY* EXIT* and 
DE8UG keypoints for the gathering of extra data. All DATA 
keypoints encountered are supplying additional date which 
will be associated with the last ENTRY* EXIT* or DEBUG 
keypoi nt. 

DATA keypoints should be used with care since the PHF 
hardware can only buffer up 16 keypoints* keypoint cluster 
can cause lost keypoints* 

The following deck defines the NOS/VE OS class constants, 

OSDKEYC 

C0NM0N 

{Define KEYPOINT CLASS Codes. 

C3NST 

oskfdata • osk$system_cl ass + 0* i OS - DATA keypoint! 
osk$unusual « osk$system_cl ass + 1* tU OS - Unusual keypoint. > 
osklentry « oskfsys tem_c lass + 2* it OS - Entry keypoint)> 
osk$exit « osk$system_cl ass + 3* CX OS - Exit keypoint} 
osk$debug « os k$sys tem_c I ass + 4; {D OS - Debug keypoint. > 

€*ca I let osdkeys 



01.1.3 KEYPOINT DATA AND IDENTIFICATION 



Upon successful execution each keypoint Instrucion will 
provide a total of 32 bits of information. Our convention uses 
12 bits of this for keypoint identification and the remaining 20 
bits as user supplied data. Try to use this 20 bits to supply 
meaningful information (taskid* segment number* file identifier* 
queue length* page number* time* etc.). The keypoint 
identification codes are defined in the attached common deck. On 
DATA class keypoints the data belongs to the previous keypoint 
and the full 32 bits is available for additional user data. 
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01.1.4 EXAMPLE ISSUING KEYPOINTS 



ENTRY keypoint with data* 

♦INLINE!* keypoint* * osk$entry> osk$m*taski d. i ndex* 
tmklexl t task) J 



UNUSUAL keypoint with no data: 

♦INLINE (•keypoint 1 * oskiunusual* 0* mmk$no_memory > i 

ENTRY keypoint with extra data* 

#INLINE ( f keypoint 1 * oskSentry* oskSm * segment., number* 

mmk$page_f ault )? 
♦INLINE ( f keypoint«* oskidata* offset, 0); 

01.1.5 KEYPOINT IDENTIFIERS 

Each area of the operating system has been given a range of 
identifiers to use for keypoints. The base for each area Is 
defined on common deck OSDKEYD. Each area should 
have a deck xxOKEY (where xx is the product identifier) 
where the areas keypoint constants are def ined(e.g .tmk$exi t.task )• 
Please reference the section on keypoint description decks* for an 
example of one of these decks. 

OSDKEYD 

COMMON 

CThls deck defines constants for use with KEYPOINTS. 

{Define base keypoint procedure identifiers for each area of the 
COS. 

CONST 

amkfbase * 100* C100 - 149} 

baklbase « 200, C200 - 249} 

clk$base « 250* C250 - 299} 

cmk$base • 300* C300 - 349} 

dbkSbase • 350* C350 - 399} 

dmklbase « 400* <400 - 549} 
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fmkSbase « 550* 


£550 - 599} 


i cklbase * 600 * 


{600 - 649} 


ifk$base * 650* 


£650 - 699} 


i ikSbase * 700* 


£700 - 749} 


Inkibase « 750* 


£750 - 799} 


jmk$base « 800* 


£800 - 849} 


IgkSbase « 850* 


£850 - 899} 


I IkSbase » 900* 


£900 - 949} 


lok$base « 950* 


£950 - 999} 


lukSbase « 1000* 


£1000 - 1049} 


mlkSbase « 105 0* 


£1050 - 1099} 


mmklmon 1 tor_base 


* 1100* £1100 - 1149} 


aunk$job_base « 1150* £1150 - 1199} 


nskSbase « 1200* 


£1200 - 1249} 


»tk$base « 1250* 


£1250 - 1299} 


ockSbase « 1300* 


£1300 - 1349} 


ofklbase * 1350* 


£1350 - 1399} 


osk$base « 1400* 


£1400 - 1449} 


pfkSbase ■ 1500* 


£1500 - 1549} 


pmklbase • 1600* 


£1600 - 1699} 


rhkSbase « 1750* 


£1750 - 1799} 


srkSbase * 1800* 


£1800 - 1819} 


stk$base » 1850* 


£1850 - 1899} 


traklfflon 1 tor .base 


* 1900* £1900 - 1949} 


tmk$job_base * 1950* C1950 - 1999> 


jskSmoni tor.base 


* 2000* £2000 - 2049} 


JskSjob.base » 2050* £2050 - 2099> 


avkSbase * 2100* 


£2100 - 2149} 


sfk$base « 2150* 


£2150 - 2199} 


lokSbase « 2200* 


£2200 - 2249} 


rmkSbase » 2250* 


£2250 - 2300} 


mtklassembl y_l anguage_base « 4000* £4000 


C OS assembly language 4000 - 4095} 


£*caf Ic* osdkeyc 





- 4095} 



01.2 MUEMiMfi-KmOUilS 
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01. 2.1 ON THE SIMULATOR 

When executing on the simulator all keypoint instructions cause 
an entry to be added to the local file SESSMKF. 



Dl.2.2 ON THE HARDWARE 

Software keypoint collection is available for collecting system 
and job keypoints. System keypoints are those keypoints in the 
entire system and job keypoints are only those dealing with a 
particular job. Only one system keypoint collector 
can be active at one time* but each job may have an active 
job keypoint collector. Software keypoints are collected on a 
file local to the Job in which the keypoint collection task Is 
running* After keypoint collection is terminated this file can 
saved on the 170 side and analyzed by the keypoint analyzer. 

Three commands are supplied to utilize the keypoint features 
KEY9N* KEYOFF, and KEYPOINT. 

Dl.2.2.1 K£XQU_££JSJ2AJK[ 

The KEYON command initiates keypoint recording and collecting. 
It has the form of* 



KEYQN*recording_mode> environment* kmm> kmj> 
keypo i nt.cl ass_start> keypo int_c I ass_stop* 
keypo int_f i I e_name* keypo i nt_buf fe resize* 
co 1 1 ector_t i meout_per i od 

r ecor dl ng_mode * •software' or 'hardware'* default is software 

environment * •job 1 or •system' * default is job 

keypotnt_mask_monitor « G .. 0ffff(16) * default is 0ffff(16) 

keypoint.mask.job * .. 0ffff(16) * default is 0ffff(16) 

keypoin t_cl ass_start * •• 15 

This specifies that keyoolnt collection should not 
start until a keypoint of this class in encountered* 
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01*2*2*1 KEYON command 

default is to begin coilecting immediately* 

keypolnt_class_stop « ** 15 

This specifies that keypoint collection should stop 
when a keypoint of this class is encountered. 

keypo lnt_f i le.name « file name on which keypoints are saved* 

used Ml th software keypoints only* default is KEYFILE* 

keypo lnt_buf fer_si ze * •• halfword # default is 200C 

For software keypoints only, 

col lector_timaout_per iod * •• halfword • default is 50 
mill Iseconds* 
For use with software keypoints only* 



01*2.2.2 &&XaE£.fiAll*XUl 

The KEYOFF command terminates keyooint collection* 
KEYQFF« environment 

Dl. 2.2.3 i£X£QIIiI_£aJBiau4 

This command is used to issue keypoints. 

KEYPOINT « keypoint_cl ass_number> keypo I nt_code 

keypolnt_cl ass_number * •• 15 • default is 15 

keypolnt^code * *• halfword # default is 



After keypoint collection is terminated the keypoint file* 
can be saved on the 170 by a REPLACE.F RE with B56 
conversion* For example. 

RE PLACE _FIl£#keyf ile#keyf i Ie.«b5& 

On the 170 side this can be analyzed by using NVEKEY* 
format « NOW* 
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01.2.2.3 KEYPOINT command 



01.3 H£I£QIM-AliILII£&-yiILIIX 



01.3.1 MYEKEY 



The SSSSMKF file produced on the simulator* or the 
KEYFILE produced on the hardware can be reformatted into a 
readable listing by executing the following procedure. 

SSS.NVEKEY CKPF* 1 CF0RMAT« 3 CKD* 3 CAREA- 3 

NVEKEY creates a simulator generated keypoint trace file. 

The "kpf" parameter is the keypoint file used as input. 

The "kd M parameter is a file or list of files which define(s) 

the keypoint descriptions. 

PARAMETER 0EFAULT ALLOCABLE VALUE S- 

kpf *S£SSHKF« f i le name 

•KEYFILE* if format»HQW 

fomat 'SIM* simjhdw 

kd 'KEYOFSC f I I e name(s) 

area 6USERS user name 



If run interactively* when the procedure terminates the 
reformatted listing is on local file KEYFILE. 



Dl.3.2 KEYPOINT DESCRIPTION FILE 

The keypoint descriptions are used by the keypoint 
analyzer utility to direct the reformatting of the 
keypoint information. 
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Each area has a keypoint constant deck xxOKEY (where xx 
is the product id). The keypoint descriptions are now 
included in this deck immediately following the keypoint 
constants (siniliar to the message templates). 

Each description has the following format. 

Note* each element (if given) is positionally dependant. 

{CLASS CSUB_I0_FIELD1 KE YPOINT.LABE L CDATA.LABE13 tDATA.^ IELD1 

CLASS of keypoint - required 
E Entry 
X eXit 
U Unusual 
Debug 

SUB_ID_FI£LD - optional - (described later) 

KEYPQXNT_LAB£L - required - This is a string that 
describes the purpose of the keypoint. 

DATA_LA8£L - optional - This is a string of up to 8 

characters describing the data portion of the keypoint. 

DATA_FIELD_DESCRIPTOR - optional - This consists of data 
foriat and length. 
data_f or mat 

H Hex 

I Integer ( decima I) 

A ASCII 
Concatenated to this Is the length of the data portion of 
the keypoint* in decimal bits. 
For examplei 120 



Dl.3.2.1.1 EXAMPLE KEYPOINT DECK 

STDKEY 

COMMON 

C PURPOSE! 

i This deck contains all of the set manager keypoint constants. 

CONST 
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stkScreate.set * stk$base + 1. 

IE •stp$create.set« 'ring » H > 

CX *stp$create.set f 'status • 120 > 

stkSpur ge.set ■ stkSbase ♦ Z» 
CE • stpSpurge.set • > 
CX 'stpSpur ge.se t' * status ' 120 > 

stkScant_dm.store_set.ord ■ stkSbase* 

CU 'cant dmp$store.avt.set.ordi na I * 'avtindx ' H20 > 

stk$pf .root. si ze ■ stklbase * 5; 

€0 » pf.root.s Ize' •rootslz ' H20 > 

?? PUSH (LIST J» OFF) ?? 
C*cal Ic osdkeyd 
?? POP ?? 



Dl.3.2.1.2 SUB.ID.FIELD 

This optional field allows a means of subdividing a single 
keypolnt into several descriptors. The particular descriptor 
is chosen on the basis of a selectable number of bits of the 
data field. This field has the following format' 

SUB. ID. LENGTH. SUB.ID.MATCH 

SUB.IO.LENGTH - This specifies the number of bits (right most) 
of the data field to use* to determine which 
descriptor to choose* 

SUB.ID.NATCH - This specifies the integer identifier used to 
match the data portion. 

Example: 

mmk$pag e.f aul t « mmk$moni tor. base + 6* 
CE *page fault processor 1 > 

CE 4*1 'Page found in avail queue 1 'pfti • H16> 

CE 4.2 'Page found in avail modified queue » 'pfti * H16> 

If this keypolnt was issued and produced data of 2» the 

descriptor with the sub. id. match field of 2 would be 

used ( v page found in avail modified queue' )• 

These keypoints were issued with a sub.i d.l ength ■ 4» 

thus the 4.x. For example? 

♦INLINE ( , keypoint'» osk$entry, osk$m * 

(pfti * 16 C2 ** sub.i d.l ength> + 2Csub.i d.match}) . 
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mmk$page_f aul t)» 



oi*3 .2.2 aafiai:AiiQa-i!ifi-.i3fis.££iata£.-fli£ 

The keypoint descriptions are kept on a file called KEYDESC 
on the Integration catalog. This file may be produced by* 

SES.GENCOMP M«0SMK£YS AB«UNOSVEPl*OSlPI# INT2)) CF-KEYOESC 

The user may add keypoints to her xxOKEY deck locally* and 
the KEYOESC file may be produced as above* specifying the 
additional local bases. The KEYOESC file may then be saved 
on her catalog. 

If new keypolnt decks are added* *cailc »s to these new decks 
cnould be added to the deck OSHKEYS* and the appropriate 
base constants added to deck OSOKEYD. 

When transmitting changes to keypolnt decks* be sure to inform 
Integration* via the transittal form* to recreate the file 
KEYOESC. 



01.3.2.3 o.sjBJS£*s_j;ox]!La£ 

This section will only be useful to those desiring to add 
additional keypoint classes* keypolnt class base constants* 
or new keypoint description decks. 

The classes* identifiers* and descriptions are each buffered 
by a continent. For example* to add another keypoint class* 
£$$$ START KEYPOINT CLASSES $$$> 
CONST 

pskfentry * osk$pr oduct_set_c I ass + 15 CE PS ~ entry keypoint! 
€$$$ ENO KEYPOINT CLASSES $$$ > 
note* The E follwoing the **C M will be used in the description. 

This new section should be appended to the end of the KEYDESC 
file. Readers desiring more information should reference the 
attached 8NF* and the attached decks 0SJ1KEYS. 

The following represents a sample of how to set up 

the description module. 

Note* Comment put around *call for sake of documentation only. 
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OSHKEYS 
?? LEFT I* 
NODULE Key 
£*ca I lc*os 
{$$$ START 
£*cat lc» os 
{$$$ END K 
{$$$ START 
Ocal let os 
£$$$ END K 
£$$$ START 



C*caf Ic 
C*cal Ic 
£*callc 
£*cal Ic 
C*cal Ic 
£*cal Ic 
£*calic 
£*callc 
£*cal Ic 
£*cal Ic 
£*eal Ic 
£*cal Ic 
Oca I Ic 
£*cai Ic 
C*cal Ic 
£*ca»tc 
£*cal Ic 
£*calic 
£*cal Ic 
£*cal Ic 
£*cailc 
£*cal Ic 
£*cal Ic 
£*cal Ic 
Ocallc 
£*eat ic 
£*cal Ic 
£*cal Ic 
C*cal Ic 
£*cal Ic 
£*ca» Ic 
£*cal Ic 
Ocallc 
£*callc 
£*cal Ic 
£*cal Ic 



am 
ba 
cl 
cm 
db 
dm 
fm 
ic 
if 
ii 
in 
jm 

I 9 
II 
10 

lu 

ml 
mm 
mm 
ms 
mt 
oc 
of 
os 

Pf 
pm 
rh 
sr 
st 
tm 
tm 
Js 
js 
av 
sf 
io 



1# RIGHT :» 110 ?? 
Point_description_fi!at 
dkeys 

KEYPOINT CLASSES $$$> 
dkeyc 
EYPQINT CLASSES $$$> 

KEYPOINT IDENTIFIER BASES $$$> 
dkeyd 
EYPOINT IDENTIFIER BASES $$$> 

KEYPOINT DESCRIPTIONS $$$> 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dmkey 
djkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dkey 
dmkey 
djkey 
dmkey 
djkey 
dkey 
dkey 
dkey 
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£*cal lc»rmdkey 

C$$$ END KEYPOINT DESCRIPTIONS S$$> 

M0DEN0 keypofnt.description.fi la) 



01. * £££QRIUII£Q-EXL£-D£5£&J£IIflll 



The output from procedure NVEKEY is a file called KEyFILE. 
This reformatted listing contains two sections. The first 
section is a listing of ail the keypoints in the order they were 
issued* The second section is a summary of the number of tiires 
each keypolnt occured. 

Each line in the first section has the following format; 

RT TSL DATA DATA.LA8EL S TN AREA. ID KP.LA3EL 

The RT field designates the value of the free running 

microsecond clock (time since deadstart) when the keypolnt was 

executed. On the simulator the clock is incremented by 1 for 
each instruction executed. 

The TSL field designates the time (microseconds) since the 
last keypolnt instruction was executed. 

The DATA field specifies the value of the data portion of the 
keypolnt in the format described in the keypolnt description 
file for this keypolnt. 

The DATA. LABEL field Is the data label field from the 
keypolnt description file for this keypolnt. 
This identifies the data being displayed. 

The S field specifies the state of the machine when the 
keypolnt was issued and is one of the following: 

H - Monitor mode 
J -■ Job mode 

An * preceding the S field indicates that 

trap processing is active* that is the trap handler has 

been entered* but not exited. 

the TN field gives the global task id of the task that 
was executing when the keypolnt was issued. 
The system is task 1. 
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The AREA. ID field is the area identifier for the area 
issuing the keypoint. 

The KP.LABEL is the keypoint label field from the keypoint 
description file* This describes the keypoint. 



NOTE* For an undefined keypoint* that is* one which has no 
descriptor entry* the area. id field contains the 
integer for the keypoint class* the class field 
on the output is specified as "UNO"* and the KP. LABEL 
be comes the id. number of the keypoint. 



01.5 E!iEJi£I£ai!iI_a£$£RlHiaM 

<ana I yzer.descr iptor_input> J s* <keypoint_class.aliocati on_deck> 

C <daf init ion.deck> ... 3 

<keypoin t.c I ass.al locat i on.deck> J * * <cybil code and/or con»ments> 

C <e I ass_base.def in i t i ons> ••• 3 
<cybi 1 code and/or comments> 

<class.base.def ini ti ons> **« <cl ass.base.i d> <spc> « <spc> <base> 

<cl ass. base. id> s:* oskSsys tem.c I ass J osk$pr oduct.set.c I ass « 

oskSuser.cl ass * oskSpmf .control 

<spc> it* t <space> ... 3 

<base> ti« <lnteger> 

<def i nit ion.deck> *i* <class.def i ni ti on.deck> J 

<base.def i ni t i on.deck> * 
<keypoint.def in! ti on_deck> 

<class.definition.deck> *:« C$$$ START KEYPOINT CLASSES $$$> 

<cybi I code and/or comn!ents> 
t <cl ass.def in itions> ••• 3 
<cybi I code and/or comnients> 

i%%% END KEYPOINT CLASSES $$$> 

<cl ass.def i nit ions> *** <keypoint_cl ass> <spc> * <spc> 
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<cl ass.base.i d> <offset> 

C <keypoint.cl ass.id> <cybil commenO 

<keypoin t.c lass> it* <identifier> 

<offset> «** + <spc> <integer> <delimiter> 

<de» imiter> *** , J ; 

<keypoint.c lass. id> **■ <character> 

<base.defi ni tlon.deek> tt» 

{$$ START KEYPOINT IDENTIFIER BASES $$$> 
<cyfoi t code and/or con!!!ients> 
t <range.base.def init ions> ••• 3 
<cybi1 code and/or comments> 
C$$$ END KEYPOINT IDENTIFIER BASES $$$> 

<range_base.def Ini ti ons> ti« <keypoint.base> <delimiter> 

<base.range> 

<keypoln t.base> *** <spc> <base.id> <spc> « <spc> <base> 

<base.id> <** <identifler> 

<bas e_range> n* <spc> { <Iow.base> <sp> - <high.base> t },1 

<lon.base> tt» <integer> 

<Mgh.base> ti« <integer> 

<keypolnt.def i ni ti on.deck> «t« 

C$$$ START KEYPOINT DESCRIPTIONS $$$> 
<cybll code and/or comaients> 
C <xxdkey_deck> ••• 1 
<cybM code and or comments> 
£%%% END KEYPOINT DESCRIPTIONS $$$> 

<xxdkey_deck> ii* C <cybil code and/or comments> 3 

C <keypoi nt.l nf o> ... 3 

<keypoint.lnfo> it* <keypolnt.constant.Mne> <dellmiter> <eol> 

C <keypoin t.descr I ptor> ••• 3 
C <b I ank I ines> 3 

<keypo!n t.constant.l ine> »»* <keypoi nt.cons tant> <spc> * <spc> 

<keypo in t.bas e> <spc> C <offset> 3 <spc> 
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<keyPoint.constant> *** <identifier> 

<key po int.b a se> **« <identifier> 

<keypoin t.descri pt or > s:» C <keypoint.descr i ptor.l ist> <spc> I > 3 

<eoi> 

<keypoint.descrtptor.list> :t« <keypoi nt.cl ass.i d> <spc> 

I <speci a l.cas e.code> 3 <spc> 
t <sub.id_f iel d> 3 <spc> <keypo i nt.l abe I > 
<spc> t <data.fi eld> 1 

<special.case.code> **« M J N J S * T 

(N » Ntr* N * Nos> S * task Switch* and T ■ T r ap) 

<sub.i d.f i eld> it* <sub.id.t engtn> • <sub.i d.maten> 

<sub.id.length> **» <f i eld. I ength> 

<f leld.length> n« 0..52 (in bits) 

<sub.id.match> n» <sma I I. in teger> 

<smal l.intager> tt« 0«.G FFFFFFFFFFFFF (16) 

<keypotnt.i abe l> n» <label> 

<label> ti* • <char aeter.str ing> * 

<char aeter.str ing> n» any visible characters except • 

<data.field> n« <data.label> <spc> C <data.f i el d.descr i ptor> 3 

<data.label> n« <label> 

<data.fi el d.descr I ptor> «*■ <data.f ormat> C <data.f i el d.l engtb> 3 

<data.format> *i« A ! H J I 

(A « Alphanumeric* H * Hex* I « Integer) 

<data.f ield.fength> n» <f i el d.l ength> 

(NOTE* <sub.id.length> ♦ <data_f i el d.l ength> roust be <» 52 bits ) 

(NOTE* operating system <keypoi nt.cl ass. I d> * {D>E*U>X>) 

(NOTE* <keypolnt. class. i d> for any keypoint used for 

additional information to previous key points 

must be a space) 

(NOTE* a <def Inltl on.deck> remains in effect until 
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superceeded by a deck which redefines the 
area to which it pertains) 
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